SageMaker notebooks granting users root on the instance
What does ZopNight detect here?
Root access on a SageMaker notebook lets any user of it install system packages, alter the OS, and disable the very lifecycle scripts meant to standardise it. ZopNight flags in-service notebooks whose rootAccess setting reads Enabled, and 1 stop-edit-start cycle turns it off, with no rebuild required.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1616 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | sagemaker_compliance.go |
Where it applies
What root on a notebook actually undoes
A notebook instance with root access is a machine its users can quietly rebuild: install arbitrary system packages, modify kernels, stop security agents, and edit the boot-time scripts an admin thought were mandatory. For a single researcher’s sandbox that may be tolerable; on a shared instance, or anywhere lifecycle configurations are doing security work, root access means every control on the box is advisory. Least privilege on notebooks is unglamorous, but it is the difference between “we provision these instances” and “users provision themselves”.
The detection condition
Discovery describes each notebook and stamps the rootAccess state into metadata only when
the describe call succeeds. The rule fires when the value is confirmed Enabled on an
in-service instance. Stopped, failed, or transitioning notebooks are skipped, because those are
covered by the deletion-review rule, and telling someone to harden an instance they are being
told to delete is contradictory noise. A notebook whose describe failed produces nothing.
Check a notebook directly
aws sagemaker describe-notebook-instance \ --notebook-instance-name my-notebook \ --query '[NotebookInstanceName,NotebookInstanceStatus,RootAccess]'Fixing it is cheap; the workflow change is the real task
The setting is mutable: stop the instance, set root access to Disabled, start it again. Nothing about the fix requires recreation. What does need thought is where users’ legitimate package needs go afterwards. The answer is a lifecycle configuration that installs the approved toolchain at start, so the capability users lose interactively is provided declaratively. Without that step, expect the request to re-enable root within the week, this time with a business justification attached.
Reading this finding at fleet scale
One flagged notebook is a setting. Twenty flagged notebooks mean root-enabled is your template’s default. Fix the template, IaC module, or console habit that creates them, and the finding class stops regenerating. There is no cost dimension here at all: the charge for a notebook is identical with root on or off, which is exactly why this ships as a compliance finding with $0 attached rather than pretending a hardening step saves money.