# SageMaker Notebook Root Access Enabled

> 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.

Source: https://zop.dev/integrations/aws/recommendations/sagemaker-notebook-root-access-enabled
Updated: 2026-08-19

---

## 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

```bash
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.