# Access control for notebooks Access Control You must use different procedures to control access to Amazon SageMaker Studio Classic notebooks and SageMaker notebook instances because they have different runtime environments. Studio Classic uses file system permissions and containers to control access to Studio Classic notebooks and isolation of users. A SageMaker notebook instance gives users that login to the notebook instance default root access. The following topics describe how to change permissions for both kinds of notebooks. **Topics** + [ # Access control and setting permissions for SageMaker Studio notebooks ](security-access-control-studio-nb.md) + [ # Control root access to a SageMaker notebook instance ](nbi-root-access.md) # Access control and setting permissions for SageMaker Studio notebooks Access control and Studio notebooks Amazon SageMaker Studio uses filesystem and container permissions for access control and isolation of Studio users and notebooks. This is one of the major differences between Studio notebooks and SageMaker notebook instances. This topic describes how permissions are set up to avoid security threats, what SageMaker AI does by default, and how the customer can customize the permissions. For more information about Studio notebooks and their runtime environment, see [Use Amazon SageMaker Studio Classic Notebooks](notebooks.md). **SageMaker AI app permissions** A *run-as user* is a POSIX user/group which is used to run the JupyterServer app and KernelGateway apps inside the container. The run-as user for the JupyterServer app is sagemaker-user (1000) by default. This user has sudo permissions to enable the installation of dependencies such as yum packages. The run-as user for the KernelGateway apps is root (0) by default. This user is able to install dependencies using pip/apt-get/conda. Due to user remapping, neither user is able to access resources or make changes to the host instance. **User remapping** SageMaker AI performs user-remapping to map a user inside the container to a user on the host instance outside the container. The range of user IDs (0 - 65535) in the container are mapped to non-privileged user IDs above 65535 on the instance. For example, sagemaker-user (1000) inside the container might map to user (200001) on the instance, where the number in parentheses is the user ID. If the customer creates a new user/group inside the container, it won't be privileged on the host instance regardless of the user/group ID. The root user of the container is also mapped to a non-privileged user on the instance. For more information, see [Isolate containers with a user namespace](https://docs.docker.com/engine/security/userns-remap/). **Note** Files created by the user sagemaker-user may look like they are owned by sagemaker-studio (uid 65534). This is a side effect of a fast app creation mode where SageMaker AI container images are pre-pulled, allowing applications to start in under a minute. If your application requires the file owner uid and the process owner uid to match, ask the customer service to remove your account number from the image pre-pull feature. **Custom image permissions** Customers can bring their own custom SageMaker images. These images can specify a different run-as user/group to launch the KernelGateway app. The customer can implement fine grained permission control inside the image, for example, to disable root access or perform other actions. The same user remapping applies here. For more information, see [Custom Images in Amazon SageMaker Studio Classic](studio-byoi.md). **Container isolation** Docker keeps a list of default capabilities that the container can use. SageMaker AI doesn’t add additional capabilities. SageMaker AI adds specific route rules to block requests to Amazon EFS and the [ instance metadata service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service) (IMDS) from the container. Customers can’t change these route rules from the container. For more information, see [Runtime privilege and Linux capabilities](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities). **App metadata access** Metadata used by running apps are mounted to the container with read-only permission. Customers aren’t able to modify this metadata from the container. For the available metadata, see [Get Amazon SageMaker Studio Classic Notebook and App Metadata](notebooks-run-and-manage-metadata.md). **User isolation on EFS** When you onboard to Studio, SageMaker AI creates an Amazon Elastic File System (EFS) volume for your domain that is shared by all Studio users in the domain. Each user gets their own private home directory on the EFS volume. This home directory is used to store the user's notebooks, Git repositories, and other data. To prevent other users in the domain from accessing the user's data, SageMaker AI creates a globally unique user ID for the user's profile and applies it as a POSIX user/group ID for the user’s home directory. **EBS access** An Amazon Elastic Block Store (Amazon EBS) volume is attached to the host instance and shared across all images. It's used for the root volume of the notebooks and stores temporary data that's generated inside the container. The storage isn't persisted when the instance running the notebooks is deleted. The root user inside the container can't access the EBS volume. **IMDS access** Due to security concerns, access to the Amazon Elastic Compute Cloud (Amazon EC2) Instance Metadata Service (IMDS) is unavailable in SageMaker Studio. For more information on IMDS, see [Instance metadata and user data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html). # Control root access to a SageMaker notebook instance Control root access to a Notebook instance By default, when you create a notebook instance, users that log into that notebook instance have root access. Data science is an iterative process that might require the data scientist to test and use different software tools and packages, so many notebook instance users need to have root access to be able to install these tools and packages. Because users with root access have administrator privileges, users can access and edit all files on a notebook instance with root access enabled. If you don't want users to have root access to a notebook instance, when you call [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateNotebookInstance.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateNotebookInstance.html) or [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateNotebookInstance.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateNotebookInstance.html) operations, set the `RootAccess` field to `Disabled`. You can also disable root access for users when you create or update a notebook instance in the Amazon SageMaker AI console. For information, see [Create an Amazon SageMaker Notebook Instance for the tutorial](gs-setup-working-env.md). **Note** Lifecycle configurations need root access to be able to set up a notebook instance. Because of this, lifecycle configurations associated with a notebook instance always run with root access even if you disable root access for users. **Note** For security reasons, Rootless Docker is installed on root-disabled notebook instances instead of regular Docker. For more information, see [Run the Docker daemon as a non-root user (Rootless mode)](https://docs.docker.com/engine/security/rootless/) ## Security considerations Lifecycle configuration scripts execute with root access and inherit the full privileges of the notebook instance's IAM execution role. Anyone (including Administrators) who has permissions to create or modify lifecycle configurations and manage notebook instances can execute code with the execution role's credentials hence please follow below best practices. Best practices: + Restrict administrative access: Grant lifecycle configuration permissions only to trusted administrators who understand the security implications. + Apply least-privilege principles: Define notebook instance execution roles with only the minimum permissions required for legitimate workloads. + Enable monitoring: Review CloudWatch Logs regularly for lifecycle configuration executions in log group `/aws/sagemaker/NotebookInstances` to detect unexpected activity. + Implement change controls: Establish approval processes for lifecycle configuration changes in production environments.