# Set up remote access Before users can connect their Remote IDE to Studio spaces, the administrator must configure permissions. This section provides instructions for administrators on how to set up their Amazon SageMaker AI domain with remote access. Different connection methods require different IAM permissions. Configure the appropriate permissions based on how your users will connect. Use the following workflow along with the permissions aligned with the connection method. **Important** Currently remote IDE connections are authenticated using IAM credentials, not IAM Identity Center. This applies for domains that use the IAM Identity Center [authentication method](https://docs.amazonaws.cn/sagemaker/latest/dg/onboard-custom.html#onboard-custom-authentication-details) for your users to access the domain. If you prefer not to use IAM authentication for remote connections, you can opt-out by disabling this feature using the `RemoteAccess` conditional key in your IAM policies. For more information, see [Remote access enforcement](remote-access-remote-setup-abac.md#remote-access-remote-setup-abac-remote-access-enforcement). When using IAM credentials, Remote IDE connections may maintain active sessions even after you log out of your IAM Identity Center session. Sometimes, these Remote IDE connections can persist for up to 12 hours. To ensure the security of your environment, administrators must review session duration settings where possible and be cautious when using shared workstations or public networks. 1. Choose one of the following connection method permissions that align with your users’ [Connection methods](remote-access.md#remote-access-connection-methods). 1. [Create a custom IAM policy](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_create.html) based on the connection method permission. **Topics** + [ ## Step 1: Configure security and permissions ](#remote-access-remote-setup-permissions) + [ ## Step 2: Enable remote access for your space ](#remote-access-remote-setup-enable) + [ # Advanced access control ](remote-access-remote-setup-abac.md) + [ # Set up Studio to run with subnets without internet access within a VPC ](remote-access-remote-setup-vpc-subnets-without-internet-access.md) + [ # Set up automated Studio space filtering when using the Amazon Toolkit ](remote-access-remote-setup-filter.md) ## Step 1: Configure security and permissions **Topics** + [ ### Method 1: Deep link permissions ](#remote-access-remote-setup-method-1-deep-link-permissions) + [ ### Method 2: Amazon Toolkit permissions ](#remote-access-remote-setup-method-2-aws-toolkit-permissions) + [ ### Method 3: SSH terminal permissions ](#remote-access-remote-setup-method-3-ssh-terminal-permissions) **Important** Using broad permissions for `sagemaker:StartSession`, especially with a wildcard resource `*` creates the risk that any user with this permission can initiate a session against any SageMaker Space app in the account. This can lead to the impact of data scientists unintentionally accessing other users’ SageMaker Spaces. For production environments, you should scope down these permissions to specific space ARNs to enforce the principle of least privilege. See [Advanced access control](remote-access-remote-setup-abac.md) for examples of more granular permission policies using resource ARNs, tags, and network-based constraints. ### Method 1: Deep link permissions For users connecting via deep links from the SageMaker UI, use the following permission and attach it to your SageMaker AI [space execution role](https://docs.amazonaws.cn/sagemaker/latest/dg/sagemaker-roles.html#sagemaker-roles-get-execution-role-space) or [domain execution role](https://docs.amazonaws.cn/sagemaker/latest/dg/sagemaker-roles.html#sagemaker-roles-get-execution-role). If the space execution role is not configured, the domain execution role is used by default. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "RestrictStartSessionOnSpacesToUserProfile", "Effect": "Allow", "Action": [ "sagemaker:StartSession" ], "Resource": "arn:*:sagemaker:*:*:space/${sagemaker:DomainId}/*", "Condition": { "ArnLike": { "sagemaker:ResourceTag/sagemaker:user-profile-arn": "arn:aws-cn:sagemaker:*:*:user-profile/${sagemaker:DomainId}/${sagemaker:UserProfileName}" } } } ] } ``` ------ ### Method 2: Amazon Toolkit permissions For users connecting through the Amazon Toolkit for Visual Studio Code extension, attach the following policy to one of the following: + For IAM authentication, attach this policy to the IAM user or role + For IdC authentication, attach this policy to the [Permission sets](https://docs.amazonaws.cn/singlesignon/latest/userguide/permissionsetsconcept.html) managed by the IdC To show only spaces relevant to the authenticated user, see [Filtering overview](remote-access-remote-setup-filter.md#remote-access-remote-setup-filter-overview). **Important** The following policy using `*` as the resource constraint is only recommended for quick testing purposes. For production environments, you should scope down these permissions to specific space ARNs to enforce the principle of least privilege. See [Advanced access control](remote-access-remote-setup-abac.md) for examples of more granular permission policies using resource ARNs, tags, and network-based constraints. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sagemaker:ListSpaces", "sagemaker:DescribeSpace", "sagemaker:ListApps", "sagemaker:DescribeApp", "sagemaker:DescribeDomain", "sagemaker:UpdateSpace", "sagemaker:CreateApp", "sagemaker:DeleteApp", "sagemaker:AddTags" ], "Resource": "*" }, { "Sid": "AllowStartSessionOnSpaces", "Effect": "Allow", "Action": "sagemaker:StartSession", "Resource": [ "arn:aws-cn:sagemaker:us-east-1:111122223333:space/domain-id/space-name-1", "arn:aws-cn:sagemaker:us-east-1:111122223333:space/domain-id/space-name-2" ] } ] } ``` ------ ### Method 3: SSH terminal permissions For SSH terminal connections, the `StartSession` API is called by the SSH proxy command script below, using the local Amazon credentials. See [Configure the Amazon CLI](https://docs.amazonaws.cn/cli/latest/userguide/cli-chap-configure.html) for information and instructions on setting up the user's local Amazon credentials. To use these permissions: 1. Attach this policy to the IAM user or role associated with the local Amazon credentials. 1. If using a named credential profile, modify the proxy command in your SSH config: ``` ProxyCommand '/home/user/sagemaker_connect.sh' '%h' YOUR_CREDENTIAL_PROFILE_NAME ``` **Note** The policy needs to be attached to the IAM identity (user/role) used in your local Amazon credentials configuration, not to the Amazon SageMaker AI domain execution role. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowStartSessionOnSpecificSpaces", "Effect": "Allow", "Action": "sagemaker:StartSession", "Resource": [ "arn:aws-cn:sagemaker:us-east-1:111122223333:space/domain-id/space-name-1", "arn:aws-cn:sagemaker:us-east-1:111122223333:space/domain-id/space-name-2" ] } ] } ``` ------ After setup, users can run `ssh my_studio_space_abc` to start up the space. For more information, see [Method 3: Connect from the terminal via SSH CLI](remote-access-local-ide-setup.md#remote-access-local-ide-setup-local-vs-code-method-3-connect-from-the-terminal-via-ssh-cli). ## Step 2: Enable remote access for your space After you set up the permissions, you must toggle on **Remote Access** and start your space in Studio before the user can connect using their Remote IDE. This setup only needs to be done once. **Note** If your users are connecting using [Method 2: Amazon Toolkit permissions](#remote-access-remote-setup-method-2-aws-toolkit-permissions), you do not necessarily need this step. Amazon Toolkit for Visual Studio users can enable remote access from the Toolkit. **Activate remote access for your Studio space** 1. [Launch Amazon SageMaker Studio](https://docs.amazonaws.cn/sagemaker/latest/dg/studio-updated-launch.html#studio-updated-launch-console). 1. Open the Studio UI. 1. Navigate to your space. 1. In the space details, toggle on **Remote Access**. 1. Choose **Run space**. # Advanced access control Amazon SageMaker AI supports [attribute-based access control (ABAC)](https://docs.amazonaws.cn/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) to achieve fine-grained access control for Remote IDE connections using ABAC policies. The following are example ABAC policies for Remote IDE connections. **Topics** + [ ## Remote access enforcement ](#remote-access-remote-setup-abac-remote-access-enforcement) + [ ## Tag-based access control ](#remote-access-remote-setup-abac-tag-based-access-control) ## Remote access enforcement Control access to resources using the `sagemaker:RemoteAccess` condition key. This is supported by both `CreateSpace` and `UpdateSpace` APIs. The following example uses `CreateSpace`. You can ensure that users cannot create spaces with remote access enabled. This helps maintain security by defaulting to more restricted access settings. The following policy ensures users can: + Create new Studio spaces where remote access is explicitly disabled + Create new Studio spaces without specifying any remote access settings ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyCreateSpaceRemoteAccessEnabled", "Effect": "Deny", "Action": [ "sagemaker:CreateSpace", "sagemaker:UpdateSpace" ], "Resource": "arn:aws-cn:sagemaker:*:*:space/*", "Condition": { "StringEquals": { "sagemaker:RemoteAccess": [ "ENABLED" ] } } }, { "Sid": "AllowCreateSpace", "Effect": "Allow", "Action": [ "sagemaker:CreateSpace", "sagemaker:UpdateSpace" ], "Resource": "arn:aws-cn:sagemaker:*:*:space/*" } ] } ``` ------ ## Tag-based access control Implement [tag-based](https://docs.amazonaws.cn/whitepapers/latest/tagging-best-practices/what-are-tags.html) access control to restrict connections based on resource and principal tags. You can ensure users can only access resources appropriate for their role and project assignments. You can use the following policy to: + Allow users to connect only to spaces that match their assigned team, environment, and cost center + Implement fine-grained access control based on organizational structure In the following example, the space is tagged with the following: ``` { "Team": "ML", "Environment": "Production", "CostCenter": "12345" } ``` You can have a role that contains the following policy to match resource and principal tags: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "RestrictStartSessionOnTaggedSpacesInDomain", "Effect": "Allow", "Action": [ "sagemaker:StartSession" ], "Resource": [ "arn:aws-cn:sagemaker:us-east-1:111122223333:space/domain-id/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/Team": "${aws:PrincipalTag/Team}", "aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}", "aws:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}", "aws:ResourceTag/IDC_UserName": "${aws:PrincipalTag/IDC_UserName}" } } } ] } ``` ------ When the role’s tags match, the user has permission to start the session and remotely connect to their space. See [Control access to Amazon resources using tags](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_tags.html) for more information. # Set up Studio to run with subnets without internet access within a VPC Set up private subnet with no internet access This guide shows you how to connect to Amazon SageMaker Studio spaces from your Remote IDE when your Amazon SageMaker AI domain runs in private subnets without internet access. You’ll learn about connectivity requirements and setup options to establish secure remote connections in isolated network environments. You can configure Amazon SageMaker Studio to run in VPC only mode with subnets without internet access. This setup enhances security for your machine learning workloads by operating in an isolated network environment where all traffic flows through the VPC. To enable external communications while maintaining security, use VPC endpoints for Amazon services and configure VPC PrivateLink for required Amazon dependencies. **IDE support for private subnet connections** The following table shows the supported connection methods for each Remote IDE when connecting to Studio spaces in private subnets without internet access. | Connection method | VS Code | Kiro | Cursor | | --- | --- | --- | --- | | HTTP Proxy support | Supported | Supported | Not supported | | Pre-packaged remote server and extensions | Supported | Not supported | Not supported | **Important** Cursor is not supported for connecting to Studio spaces in private subnets without outbound internet access. **Topics** + [ ## Studio remote access network requirements ](#remote-access-remote-setup-vpc-subnets-without-internet-access-network-requirements) + [ ## Setup Studio remote access network ](#remote-access-remote-setup-vpc-subnets-without-internet-access-setup) ## Studio remote access network requirements **VPC mode limitations** Studio in VPC mode only supports private subnets. Studio cannot work with subnets directly attached with an Internet Gateway (IGW). Remote IDE connections share the same limitations as SageMaker AI. For more information, see [Connect Studio notebooks in a VPC to external resources](https://docs.amazonaws.cn/sagemaker/latest/dg/studio-notebooks-and-internet-access.html). ### VPC PrivateLink requirements When SageMaker AI runs in private subnets, configure these SSM VPC endpoints in addition to standard VPC endpoints required for SageMaker. For more information, see [Connect Studio Through a VPC Endpoint](https://docs.amazonaws.cn/sagemaker/latest/dg/studio-interface-endpoint.html). + `com.amazonaws.REGION.ssm` + `com.amazonaws.REGION.ssmmessages` **VPC endpoint policy recommendations** The following are the recommended VPC endpoint policies that allow the necessary actions for remote access while using the `aws:PrincipalIsAWSService` condition to ensure only Amazon services like Amazon SageMaker AI can make the calls. For more information about the `aws:PrincipalIsAWSService` condition key, see [the documentation](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalisawsservice). **SSM endpoint policy** Use the following policy for the `com.amazonaws.REGION.ssm` endpoint: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": [ "ssm:CreateActivation", "ssm:RegisterManagedInstance", "ssm:DeleteActivation", "ssm:DeregisterManagedInstance", "ssm:AddTagsToResource", "ssm:UpdateInstanceInformation", "ssm:UpdateInstanceAssociationStatus", "ssm:DescribeInstanceInformation", "ssm:ListInstanceAssociations", "ssm:ListAssociations", "ssm:GetDocument", "ssm:PutInventory" ], "Resource": "*", "Condition": { "BoolIfExists": { "aws:PrincipalIsAWSService": "true" } } } ] } ``` **SSM Messages endpoint policy** Use the following policy for the `com.amazonaws.REGION.ssmmessages` endpoint: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": [ "ssmmessages:CreateControlChannel", "ssmmessages:CreateDataChannel", "ssmmessages:OpenControlChannel", "ssmmessages:OpenDataChannel" ], "Resource": "*", "Condition": { "BoolIfExists": { "aws:PrincipalIsAWSService": "true" } } } ] } ``` **VS Code specific network requirements** Remote VS Code connection requires VS Code remote development, which needs specific network access to install the remote server and extensions. See the [remote development FAQ](https://code.visualstudio.com/docs/remote/faq) in the Visual Studio Code documentation for full network requirements. The following is a summary of the requirements: + Access to Microsoft’s VS Code server endpoints is needed to install and update the VS Code remote server. + Access to Visual Studio Marketplace and related CDN endpoints is required for installing VS Code extensions through the extension panel (alternatively, extensions can be installed manually using VSIX files without internet connection). + Some extensions may require access to additional endpoints for downloading their specific dependencies. See the extension’s documentation for their specific connectivity requirements. **Kiro specific network requirements** Remote Kiro connection requires Kiro remote development, which needs specific network access to install the remote server and extensions. For firewall and proxy server configuration, see [Kiro firewall configuration](https://kiro.dev/docs/privacy-and-security/firewalls/). The requirements are similar to VS Code: + Access to Kiro server endpoints is needed to install and update the Kiro remote server. + Access to extension marketplace and related CDN endpoints is required for installing Kiro extensions through the extension panel. + Some extensions may require access to additional endpoints for downloading their specific dependencies. See the extension’s documentation for their specific connectivity requirements. ## Setup Studio remote access network You have the following options to connect your Remote IDE to Studio spaces in private subnets: + HTTP Proxy (supported for VS Code and Kiro) + Pre-packaged remote server and extensions (VS Code only) ### Set up HTTP Proxy with controlled allow-listing When your Studio space is behind a firewall or proxy, allow access to your IDE server and extension-related CDNs and endpoints. 1. Set up a public subnet to run the HTTP proxy (such as Squid), where you can configure which websites to allow. Ensure that the HTTP proxy is accessible by SageMaker spaces. 1. The public subnet can be in the same VPC used by the Studio or in separate VPC peered with all the VPCs used by Amazon SageMaker AI domains. ### Set up Pre-packaged remote server and extensions (VS Code only) **Note** This option is only available for Visual Studio Code. Kiro and Cursor do not support pre-packaged remote server setup. When your Studio spaces can’t access external endpoints to download VS Code remote server and extensions, you can pre-package them. With this approach, you export a tarball containing the `.VS Code-server` directory for a specific version of VS Code. Then, you use a SageMaker AI Lifecycle Configuration (LCC) script to copy and extract the tarball into the home directory (`/home/sagemaker-user`) of the Studio spaces. This LCC-based solution works with both Amazon-provided and custom images. Even when you’re not using private subnets, this approach accelerates the setup of the VS Code remote server and pre-installed extensions. **Instructions for pre-packaging your VS Code remote server and extensions** 1. Install VS Code on your local machine. 1. Launch a Linux-based (x64) Docker container with SSH enabled, either locally or via a Studio space with internet access. We recommend using a temporary Studio space with remote access and internet enabled for simplicity. 1. Connect your installed VS Code to the local Docker container via Remote SSH or connect to the Studio space via the Studio remote VS Code feature. VS Code installs the remote server into `.VS Code-server` in the home directory in the remote container during connection. See [Example Dockerfile usage for pre-packaging your VS Code remote server and extensions](remote-access-local-ide-setup-vpc-no-internet.md#remote-access-local-ide-setup-vpc-no-internet-pre-packaged-vs-code-remote-server-and-extensions-example-dockerfile) for more information. 1. After connecting remotely, ensure you use the VS Code Default profile. 1. Install the required VS Code extensions and validate their functionality. For example, create and run a notebook to install Jupyter notebook-related extensions in the VS Code remote server. Ensure you [install the Amazon Toolkit for Visual Studio Code extension](https://docs.amazonaws.cn/toolkit-for-visual-studio/latest/user-guide/setup.html) after connecting to the remote container. 1. Archive the `$HOME/.VS Code-server` directory (for example, `VS Code-server-with-extensions-for-1.100.2.tar.gz`) in either the local Docker container or in the terminal of the remotely connected Studio space. 1. Upload the tarball to Amazon S3. 1. Create an [LCC script](https://docs.amazonaws.cn/sagemaker/latest/dg/studio-lifecycle-configurations.html) ([Example LCC script (LCC-install-VS Code-server-v1.100.2)](remote-access-local-ide-setup-vpc-no-internet.md#remote-access-local-ide-setup-vpc-no-internet-pre-packaged-vs-code-remote-server-and-extensions-example-lcc)) that: + Downloads the specific archive from Amazon S3. + Extracts it into the home directory when a Studio space in a private subnet launches. 1. (Optional) Extend the LCC script to support per-user VS Code server tarballs stored in user-specific Amazon S3 folders. 1. (Optional) Maintain version-specific LCC scripts ([Example LCC script (LCC-install-VS Code-server-v1.100.2)](remote-access-local-ide-setup-vpc-no-internet.md#remote-access-local-ide-setup-vpc-no-internet-pre-packaged-vs-code-remote-server-and-extensions-example-lcc)) that you can attach to your spaces, ensuring compatibility between your local VS Code client and the remote server. # Set up automated Studio space filtering when using the Amazon Toolkit Set up auto space filtering Users can filter spaces in the Amazon Toolkit for Visual Studio Code explorer to display only relevant spaces. This section provides information on filtering and how to set up automated filtering. This setup only applies when using the [Method 2: Amazon Toolkit in the Remote IDE](remote-access-local-ide-setup.md#remote-access-local-ide-setup-local-vs-code-method-2-aws-toolkit-in-vs-code) method to connect from your Remote IDE to Amazon SageMaker Studio spaces. See [Set up remote access](remote-access-remote-setup.md) for more information. **Topics** + [ ## Filtering overview ](#remote-access-remote-setup-filter-overview) + [ ## Set up when connecting with IAM credentials ](#remote-access-remote-setup-filter-set-up-iam-credentials) ## Filtering overview **Manual filtering** allows users to manually select which user profiles to display spaces for through the Amazon Toolkit interface. This method works for all authentication types and takes precedence over automated filtering. To manually filter, see [Manual filtering](remote-access-local-ide-setup-filter.md#remote-access-local-ide-setup-filter-manual). **Automated filtering** automatically shows only spaces relevant to the authenticated user. This filtering behavior depends on the authentication method during sign-in. See [connecting to Amazon from the Toolkit](https://docs.amazonaws.cn/toolkit-for-vscode/latest/userguide/connect.html#connect-to-aws) in the Toolkit for VS Code User Guide for more information. The following lists the sign-in options. + **Authenticate and connect with SSO**: Automated filtering works by default. + **Authenticate and connect with IAM credentials**: Automated filtering **requires administrator setup** for the following IAM credentials. Without this setup, Amazon Toolkit cannot identify which spaces belong to the user, so all spaces are shown by default. + **Using IAM user credentials** + **Using assumed IAM role session credentials** ## Set up when connecting with IAM credentials **When using IAM user credentials** Toolkit for VS Code can match spaces belonging to user profiles that start with the authenticated IAM user name or assumed role session name. To set this up: **Note** Administrators must configure Studio user profile names to follow this naming convention for automated filtering to work correctly. + Administrators must ensure Studio user profile names follow the naming convention: + For IAM users: prefix with `IAM-user-name-` + For assumed roles: prefix with `assumed-role-session-name-` + `aws sts get-caller-identity` returns the identity information used for matching + Spaces belonging to the matched user profiles will be automatically filtered in the Toolkit for VS Code **When using assumed IAM role session credentials** In addition to the setup when using IAM user credentials above, you will need to ensure session ARNs include user identifiers as prefixes that match. You can configure trust policies that ensure session ARNs include user identifiers as prefixes. [Create a trust policy](https://docs.amazonaws.cn/IAM/latest/UserGuide/access_policies_create.html) and attach it to the assumed role used for authentication. This setup is not required for direct IAM user credentials or IdC authentication. **Set up trust policy for IAM role session credentials example** Create a trust policy that enforces role sessions to include the IAM user name. The following is an example policy: ``` { "Statement": [ { "Sid": "RoleTrustPolicyRequireUsernameForSessionName", "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": {"AWS": "arn:aws:iam::ACCOUNT:root"}, "Condition": { "StringLike": {"sts:RoleSessionName": "${aws:username}"} } } ] } ```