Skip to main content
emnode
Sign up
Compliance Medium severity

AWS Security Hub · SageMaker

SageMaker.14: Monitoring schedules network isolation

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub SageMaker.14 check?

SageMaker.14 fails when a monitoring schedule has `EnableNetworkIsolation` (inside its `NetworkConfig`) set to false. The check targets the schedule itself (not the underlying job definition) because the schedule carries the NetworkConfig that governs each recurring run.

Why does SageMaker.14 matter?

Each scheduled monitoring run launches internet-enabled unless isolation is set. Without it the recurring job container can reach the internet and AWS APIs, and retains runtime credentials: a standing outbound path that fires on every schedule. Isolation cuts that off, at the cost of planning VPC and S3 access so the job can still reach its data.

How do I fix SageMaker.14?

  1. List monitoring schedules and inspect `NetworkConfig.EnableNetworkIsolation` for those set to false.
  2. Use UpdateMonitoringSchedule (or recreate via CreateMonitoringSchedule) to enable isolation on the schedule.
  3. Plan VPC endpoints or staged data so the isolated runs can still reach the inputs they need.
  4. Default new schedules to isolation on, and clear siblings .11 and .12 in the same pass.

Remediation script · bash

# Disable root across every notebook that has it on (mutable on a stopped instance).
for n in $(aws sagemaker list-notebook-instances \
    --query 'NotebookInstances[].NotebookInstanceName' --output text); do
  root=$(aws sagemaker describe-notebook-instance --notebook-instance-name "$n" \
    --query 'RootAccess' --output text)
  if [ "$root" = "Enabled" ]; then
    aws sagemaker stop-notebook-instance --notebook-instance-name "$n"
    aws sagemaker wait notebook-instance-stopped --notebook-instance-name "$n"
    aws sagemaker update-notebook-instance --notebook-instance-name "$n" --root-access Disabled
    aws sagemaker start-notebook-instance --notebook-instance-name "$n"
    echo "$n: root access disabled"
  fi
done

# Immutable settings need a rebuild. Recreate a notebook locked down: private subnet,
# no direct internet. (DirectInternetAccess and SubnetId cannot be changed in place.)
aws sagemaker create-notebook-instance \
  --notebook-instance-name ml-feature-exploration \
  --instance-type ml.t3.medium \
  --role-arn arn:aws:iam::111122223333:role/SageMakerExecution \
  --subnet-id subnet-0ab12cd34ef56 \
  --security-group-ids sg-0aa11bb22cc33 \
  --direct-internet-access Disabled \
  --root-access Disabled

Full walkthrough (console steps, edge cases and verification) in the lesson Harden SageMaker and ML workloads.

Is SageMaker.14 a false positive?

Network isolation severs all outbound calls and strips runtime credentials, so a schedule that legitimately needs to reach an external endpoint (pulling ground-truth labels from a third-party API, posting metrics to a service outside your VPC, or invoking a SaaS data source) must run with EnableNetworkIsolation off, and that is the correct state, not a misconfiguration. Forcing isolation on such a schedule breaks the monitoring run rather than securing it. Where you accept that path deliberately, document a Security Hub suppression that names the schedule and the egress it depends on, and compensate by locking down the schedule's VPC config, security groups, and IAM role so the outbound path is tightly scoped rather than open.

Full lesson Harden SageMaker and ML workloads Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for SageMaker controls ↗ Check your own account for SageMaker.14 →
Part of the learning path Lock down access

More SageMaker controls