Skip to main content
emnode
Sign up
Compliance High severity

AWS Security Hub · SageMaker

SageMaker.3: Users have root access on a SageMaker notebook

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub SageMaker.3 check?

SageMaker.3 fails when a notebook instance has `RootAccess` set to `Enabled`, letting users on the notebook operate as root on the underlying Linux host.

Why does SageMaker.3 matter?

The notebook carries an IAM execution role, and root turns a single notebook into a privilege-escalation path. A user can lift the role's temporary credentials from the instance metadata endpoint and, with root, install tooling, switch users and persist on the box. Disabling root means the role's scope, not the OS, becomes the only thing between a notebook and your data lake.

How do I fix SageMaker.3?

  1. List notebook instances and check `RootAccess` to find those with it enabled.
  2. For each one, stop the instance, update it with `RootAccess` set to `Disabled`, then start it again.
  3. Tighten the execution role to least privilege so a credential lift reaches as little as possible.
  4. Bake `RootAccess=Disabled` into your provisioning templates and lifecycle policies so it stays off.

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.3 a false positive?

A small number of notebooks legitimately need `RootAccess=Enabled`, chiefly because interactive users have to `pip`/`conda`/`yum` install system-level packages or write outside their home directory from within the notebook session, which fails without root. (Note this does not apply to lifecycle configuration scripts: those always run with root access even when root access is disabled for users, so disabling root does not break them.) That is a real, intended setting, not a misconfiguration, so don't flip it back and break those workflows. Pin the instance to a single owner with a tightly scoped execution role (so a credential lift from the metadata endpoint reaches as little as possible), then record a documented exception in Security Hub with a workflow status of `SUPPRESSED` and a note pointing at the workload that requires it.

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.3 →
Part of the learning path Lock down access

More SageMaker controls