Secure Amazon SageMaker Studio presigned URLs Part 1: Foundational infrastructure

{"value":"You can access Amazon SageMaker Studio notebooks from the Amazon SageMaker console via AWS Identity and Access Management (IAM) authenticated federation from your identity provider (IdP), such as Okta. When a Studio user opens the notebook link, Studio validates the federated user’s IAM policy to authorize access, and generates and resolves the presigned URL for the user. Because the SageMaker console runs on an internet domain, this generated presigned URL is visible in the browser session. This presents an undesired threat vector for exfiltration and gaining access to customer data when proper access controls are not enforced.\n\nStudio supports a few methods for enforcing access controls against presigned URL data exfiltration:\n\n- Client IP validation using the IAM policy condition ```\naws:sourceIp```\n\n- Client VPC validation using the IAM condition ```aws:sourceVpc```\n\n- Client VPC endpoint validation using the IAM policy condition ```aws:sourceVpce```\n\n\nWhen you access Studio notebooks from the SageMaker console, the only available option is to use client IP validation with the IAM policy condition ```aws:sourceI```. However, you can use browser traffic routing products such as Zscaler to ensure scale and compliance for your workforce internet access. These traffic routing products generate their own source IP, whose IP range is not controlled by the enterprise customer. This makes it impossible for these enterprise customers to use the ```aws:sourceIp``` condition.\n\nTo use client VPC endpoint validation using the IAM policy condition ```aws:sourceVpce```, the creation of a presigned URL needs to originate in the same customer VPC where Studio is deployed, and resolution of the presigned URL needs to happen via a Studio VPC endpoint on the customer VPC. This resolution of the presigned URL during access time for corporate network users can be accomplished using DNS forwarding rules (both in Zscaler and corporate DNS) and then into the customer VPC endpoint using an [Amazon Route 53](https://aws.amazon.com/cn/route53/) inbound resolver.\n\nIn this part, we discuss the overarching architecture for securing studio pre-signed url and demonstrate how to set up the foundational infrastructure to create and launch a Studio presigned URL through your VPC endpoint over a private network without traversing the internet. This serves as the foundational layer for preventing data exfiltration by external bad actors gaining access to Studio pre-signed URL and unauthorized or spoofed corporate user access within a corporate environment.\n\n#### **Solution overview**\n\nThe following diagram illustrates over-arching solution architecture.\n\n\n\nThe process includes the following steps:\n\n1. A corporate user authenticates via their IdP, connects to their corporate portal, and opens the Studio link from the corporate portal.\n2. The corporate portal application makes a private API call using an API Gateway VPC endpoint to create a presigned URL.\n3. The API Gateway VPC endpoint “create presigned URL” call is forwarded to the Route 53 inbound resolver on the customer VPC as configured in the corporate DNS.\n4. The VPC DNS resolver resolves it to the API Gateway VPC endpoint IP. Optionally, it looks up a private hosted zone record if it exists.\n5. The API Gateway VPC endpoint routes the request via the Amazon private network to the “create presigned URL API” running in the API Gateway service account.\n6. API Gateway invokes the ```create-pre-signedURL```private API and proxies the request to the ```create-pre-signedURL```AWS Lambda function.\n7. The ```create-pre-signedURL```Lambda call is invoked via the Lambda VPC endpoint.\n8. The ```create-pre-signedURL```function runs in the service account, retrieves authenticated user context (user ID, Region, and so on), looks up a mapping table to identify the SageMaker domain and user profile identifier, makes a ```sagemaker createpre-signedDomainURL```API call, and generates a presigned URL. The Lambda service role has the source VPC endpoint conditions defined for the SageMaker API and Studio.\n9. The generated presigned URL is resolved over the Studio VPC endpoint.\n10. Studio validates that the presigned URL is being accessed via the customer’s VPC endpoint defined in the policy, and returns the result.\n11. The Studio notebook is returned to the user’s browser session over the corporate network without traversing the internet.\n\nThe following sections walk you through how to implement this architecture to resolve Studio presigned URLs from a corporate network using VPC endpoints. We demonstrate a complete implementation by showing the following steps:\n\n1. Set up the foundational architecture.\n2. Configure the corporate app server to access a SageMaker presigned URL via a VPC endpoint.\n3. Set up and launch Studio from the corporate network.\n\n#### **Set up the foundational architecture**\n\nIn the post [Access an Amazon SageMaker Studio notebook from a corporate network](https://aws.amazon.com/cn/blogs/machine-learning/access-an-amazon-sagemaker-studio-notebook-from-a-corporate-network/), we demonstrated how to resolve a presigned URL domain name for a Studio notebook from a corporate network without traversing the internet. You can follow the instructions in that post to set up the foundational architecture, and then return to this post and proceed to the next step.\n\n#### **Configure the corporate app server to access a SageMaker presigned URL via a VPC endpoint**\n\nTo enable accessing Studio from your internet browser, we set up an on-premises app server on Windows Server on the on-premises VPC public subnet. However, the DNS queries for accessing Studio are routed through the corporate (private) network. Complete the following steps to configure routing Studio traffic through the corporate network:\n\n1. Connect to your on-premises Windows app server.\n\n \n\n2. Choose Get Password then browse and upload your private key to decrypt your password.\n\n\n\n3. Use an RDP client and connect to the Windows Server using your credentials.Resolving Studio DNS from the Windows Server command prompt results in using public DNS servers, as shown in the following screenshot.\n\n\nNow we update Windows Server to use the on-premises DNS server that we set up earlier.\n4. Navigate to Control Panel, Network and Internet, and choose Network Connections.\n5. Right-click Ethernet and choose the Properties tab.\n6. Update Windows Server to use the on-premises DNS server.\n\n\n7. Now you update your preferred DNS server with your DNS server IP.\n\n\n8. Navigate to VPC and Route Tables and choose your STUDIO-ONPREM-PUBLIC-RT route table.\n9. Add a route to 10.16.0.0/16 with the target as the peering connection that we created during the foundational architecture setup.\n\n#### **Set up and launch Studio from your corporate network**\n\nTo set up and launch Studio, complete the following steps:\n\n1. Download Chrome and launch the browser on this Windows instance.\nYou may need to [turn off Internet Explorer Enhanced Security Configuration](https://docs.microsoft.com/en-us/troubleshoot/developer/browsers/security-privacy/enhanced-security-configuration-faq#how-to-turn-off-internet-explorer-esc-on-windows-servers) to allow file downloads and then enable file downloads.\n2. In your local device Chrome browser, navigate to the SageMaker console and open the Chrome developer tools **Network** tab.\n3. Launch the Studio app and observe the **Network** tab for the ```authtoken```parameter value, which includes the generated presigned URL along with the remote server address that the URL is routed to for resolution.In this example, the remote address 100.21.12.108 is one of the public DNS server addresses to resolve the SageMaker DNS domain ```name d-h4cy01pxticj.studio.us-west-2.sagemaker.aws```.\n\n\n4. Repeat these steps from the [Amazon Elastic Compute Cloud ](https://aws.amazon.com/cn/ec2/)(Amazon EC2) Windows instance that you configured as part of the foundational architecture.\nWe can observe that the remote address is not the public DNS IP, instead it’s the Studio VPC endpoint 10.16.42.74.\n\n#### **Conclusion**\n\nIn this post, we demonstrated how to resolve a Studio presigned URL from a corporate network using Amazon private VPC endpoints without exposing the presigned URL resolution to the internet. This further secures your enterprise security posture for accessing Studio from a corporate network for building highly secure machine learning workloads on SageMaker. In [part 2](https://aws.amazon.com/cn/blogs/machine-learning/secure-amazon-sagemaker-studio-presigned-urls-part-2-private-api-with-jwt-authentication/) of this series, we further extend this solution to demonstrate how to build a private API for accessing Studio with ```aws:sourceVPCE```IAM policy validation and token authentication. Try out this solution and leave your feedback in the comments!\n\n ——————————————————————————————————————————\n\n#### **About the Authors**\n\n **Ram Vittal** is a machine learning solutions architect at AWS. He has over 20+ years of experience architecting and building distributed, hybrid and cloud applications. He is passionate about building secure and scalable AI/ML and Big Data solutions to help enterprise customers with their cloud adoption and optimization journey to improve their business outcomes. In his spare time, he enjoys tennis and photography.\n\n **Neelam Koshiya** is an enterprise solution architect at AWS. Her current focus is to help enterprise customers with their cloud adoption journey for strategic business outcomes. In her spare time, she enjoys reading and being outdoors.\n\n\n\n\n\n","render":"<p>You can access Amazon SageMaker Studio notebooks from the Amazon SageMaker console via AWS Identity and Access Management (IAM) authenticated federation from your identity provider (IdP), such as Okta. When a Studio user opens the notebook link, Studio validates the federated user’s IAM policy to authorize access, and generates and resolves the presigned URL for the user. Because the SageMaker console runs on an internet domain, this generated presigned URL is visible in the browser session. This presents an undesired threat vector for exfiltration and gaining access to customer data when proper access controls are not enforced.</p>\n<p>Studio supports a few methods for enforcing access controls against presigned URL data exfiltration:</p>\n<ul>\n<li>\n<p>Client IP validation using the IAM policy condition <code> aws:sourceIp</code></p>\n</li>\n<li>\n<p>Client VPC validation using the IAM condition <code>aws:sourceVpc</code></p>\n</li>\n<li>\n<p>Client VPC endpoint validation using the IAM policy condition <code>aws:sourceVpce</code></p>\n</li>\n</ul>\n<p>When you access Studio notebooks from the SageMaker console, the only available option is to use client IP validation with the IAM policy condition <code>aws:sourceI</code>. However, you can use browser traffic routing products such as Zscaler to ensure scale and compliance for your workforce internet access. These traffic routing products generate their own source IP, whose IP range is not controlled by the enterprise customer. This makes it impossible for these enterprise customers to use the <code>aws:sourceIp</code> condition.</p>\n<p>To use client VPC endpoint validation using the IAM policy condition <code>aws:sourceVpce</code>, the creation of a presigned URL needs to originate in the same customer VPC where Studio is deployed, and resolution of the presigned URL needs to happen via a Studio VPC endpoint on the customer VPC. This resolution of the presigned URL during access time for corporate network users can be accomplished using DNS forwarding rules (both in Zscaler and corporate DNS) and then into the customer VPC endpoint using an <a href=\"https://aws.amazon.com/cn/route53/\" target=\"_blank\">Amazon Route 53</a> inbound resolver.</p>\n<p>In this part, we discuss the overarching architecture for securing studio pre-signed url and demonstrate how to set up the foundational infrastructure to create and launch a Studio presigned URL through your VPC endpoint over a private network without traversing the internet. This serves as the foundational layer for preventing data exfiltration by external bad actors gaining access to Studio pre-signed URL and unauthorized or spoofed corporate user access within a corporate environment.</p>\n<h4><a id=\"Solution_overview_18\"></a><strong>Solution overview</strong></h4>\n<p>The following diagram illustrates over-arching solution architecture.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/5fba5303483a4d85bfa305c6129366bb_image.png\" alt=\"image.png\" /></p>\n<p>The process includes the following steps:</p>\n<ol>\n<li>A corporate user authenticates via their IdP, connects to their corporate portal, and opens the Studio link from the corporate portal.</li>\n<li>The corporate portal application makes a private API call using an API Gateway VPC endpoint to create a presigned URL.</li>\n<li>The API Gateway VPC endpoint “create presigned URL” call is forwarded to the Route 53 inbound resolver on the customer VPC as configured in the corporate DNS.</li>\n<li>The VPC DNS resolver resolves it to the API Gateway VPC endpoint IP. Optionally, it looks up a private hosted zone record if it exists.</li>\n<li>The API Gateway VPC endpoint routes the request via the Amazon private network to the “create presigned URL API” running in the API Gateway service account.</li>\n<li>API Gateway invokes the <code>create-pre-signedURL</code>private API and proxies the request to the <code>create-pre-signedURL</code>AWS Lambda function.</li>\n<li>The <code>create-pre-signedURL</code>Lambda call is invoked via the Lambda VPC endpoint.</li>\n<li>The <code>create-pre-signedURL</code>function runs in the service account, retrieves authenticated user context (user ID, Region, and so on), looks up a mapping table to identify the SageMaker domain and user profile identifier, makes a <code>sagemaker createpre-signedDomainURL</code>API call, and generates a presigned URL. The Lambda service role has the source VPC endpoint conditions defined for the SageMaker API and Studio.</li>\n<li>The generated presigned URL is resolved over the Studio VPC endpoint.</li>\n<li>Studio validates that the presigned URL is being accessed via the customer’s VPC endpoint defined in the policy, and returns the result.</li>\n<li>The Studio notebook is returned to the user’s browser session over the corporate network without traversing the internet.</li>\n</ol>\n<p>The following sections walk you through how to implement this architecture to resolve Studio presigned URLs from a corporate network using VPC endpoints. We demonstrate a complete implementation by showing the following steps:</p>\n<ol>\n<li>Set up the foundational architecture.</li>\n<li>Configure the corporate app server to access a SageMaker presigned URL via a VPC endpoint.</li>\n<li>Set up and launch Studio from the corporate network.</li>\n</ol>\n<h4><a id=\"Set_up_the_foundational_architecture_44\"></a><strong>Set up the foundational architecture</strong></h4>\n<p>In the post <a href=\"https://aws.amazon.com/cn/blogs/machine-learning/access-an-amazon-sagemaker-studio-notebook-from-a-corporate-network/\" target=\"_blank\">Access an Amazon SageMaker Studio notebook from a corporate network</a>, we demonstrated how to resolve a presigned URL domain name for a Studio notebook from a corporate network without traversing the internet. You can follow the instructions in that post to set up the foundational architecture, and then return to this post and proceed to the next step.</p>\n<h4><a id=\"Configure_the_corporate_app_server_to_access_a_SageMaker_presigned_URL_via_a_VPC_endpoint_48\"></a><strong>Configure the corporate app server to access a SageMaker presigned URL via a VPC endpoint</strong></h4>\n<p>To enable accessing Studio from your internet browser, we set up an on-premises app server on Windows Server on the on-premises VPC public subnet. However, the DNS queries for accessing Studio are routed through the corporate (private) network. Complete the following steps to configure routing Studio traffic through the corporate network:</p>\n<ol>\n<li>Connect to your on-premises Windows app server.</li>\n</ol>\n<p><img src=\"https://dev-media.amazoncloud.cn/a84ec89b0c9d45e79c330f4942417a81_image.png\" alt=\"image.png\" /><br />\n<img src=\"https://dev-media.amazoncloud.cn/41c8ea960d81497eba5e53e38d454f01_image.png\" alt=\"image.png\" /><br />\n2. Choose Get Password then browse and upload your private key to decrypt your password.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/51a4fe867f1349b3b3639d8bfecba2d5_image.png\" alt=\"image.png\" /><br />\n<img src=\"https://dev-media.amazoncloud.cn/88c8e12634eb4c37b9f7314d7fb26b12_image.png\" alt=\"image.png\" /><br />\n3. Use an RDP client and connect to the Windows Server using your credentials.Resolving Studio DNS from the Windows Server command prompt results in using public DNS servers, as shown in the following screenshot.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/79cd5574dcca40659b8ae173dc9721c5_image.png\" alt=\"image.png\" /><br />\nNow we update Windows Server to use the on-premises DNS server that we set up earlier.<br />\n4. Navigate to Control Panel, Network and Internet, and choose Network Connections.<br />\n5. Right-click Ethernet and choose the Properties tab.<br />\n6. Update Windows Server to use the on-premises DNS server.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/778aea2faa9c4f56a66d72cc2f34030b_image.png\" alt=\"image.png\" /><br />\n7. Now you update your preferred DNS server with your DNS server IP.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/d8d8b0d443a84dbfbcc01877a334b9b1_image.png\" alt=\"image.png\" /><br />\n8. Navigate to VPC and Route Tables and choose your STUDIO-ONPREM-PUBLIC-RT route table.<br />\n9. Add a route to 10.16.0.0/16 with the target as the peering connection that we created during the foundational architecture setup.</p>\n<h4><a id=\"Set_up_and_launch_Studio_from_your_corporate_network_75\"></a><strong>Set up and launch Studio from your corporate network</strong></h4>\n<p>To set up and launch Studio, complete the following steps:</p>\n<ol>\n<li>Download Chrome and launch the browser on this Windows instance.<br />\nYou may need to <a href=\"https://docs.microsoft.com/en-us/troubleshoot/developer/browsers/security-privacy/enhanced-security-configuration-faq#how-to-turn-off-internet-explorer-esc-on-windows-servers\" target=\"_blank\">turn off Internet Explorer Enhanced Security Configuration</a> to allow file downloads and then enable file downloads.</li>\n<li>In your local device Chrome browser, navigate to the SageMaker console and open the Chrome developer tools <strong>Network</strong> tab.</li>\n<li>Launch the Studio app and observe the <strong>Network</strong> tab for the <code>authtoken</code>parameter value, which includes the generated presigned URL along with the remote server address that the URL is routed to for resolution.In this example, the remote address 100.21.12.108 is one of the public DNS server addresses to resolve the SageMaker DNS domain <code>name d-h4cy01pxticj.studio.us-west-2.sagemaker.aws</code>.</li>\n</ol>\n<p><img src=\"https://dev-media.amazoncloud.cn/70a2646547fc4cbfb5f0b22bf8c6eb78_image.png\" alt=\"image.png\" /><br />\n4. Repeat these steps from the <a href=\"https://aws.amazon.com/cn/ec2/\" target=\"_blank\">Amazon Elastic Compute Cloud </a>(Amazon EC2) Windows instance that you configured as part of the foundational architecture.<br />\nWe can observe that the remote address is not the public DNS IP, instead it’s the Studio VPC endpoint 10.16.42.74.</p>\n<h4><a id=\"Conclusion_88\"></a><strong>Conclusion</strong></h4>\n<p>In this post, we demonstrated how to resolve a Studio presigned URL from a corporate network using Amazon private VPC endpoints without exposing the presigned URL resolution to the internet. This further secures your enterprise security posture for accessing Studio from a corporate network for building highly secure machine learning workloads on SageMaker. In <a href=\"https://aws.amazon.com/cn/blogs/machine-learning/secure-amazon-sagemaker-studio-presigned-urls-part-2-private-api-with-jwt-authentication/\" target=\"_blank\">part 2</a> of this series, we further extend this solution to demonstrate how to build a private API for accessing Studio with <code>aws:sourceVPCE</code>IAM policy validation and token authentication. Try out this solution and leave your feedback in the comments!</p>\n<pre><code> ——————————————————————————————————————————\n</code></pre>\n<h4><a id=\"About_the_Authors_94\"></a><strong>About the Authors</strong></h4>\n<p><img src=\"https://dev-media.amazoncloud.cn/ed442b620db74855ae8eaa1e636222be_image.png\" alt=\"image.png\" /> <strong>Ram Vittal</strong> is a machine learning solutions architect at AWS. He has over 20+ years of experience architecting and building distributed, hybrid and cloud applications. He is passionate about building secure and scalable AI/ML and Big Data solutions to help enterprise customers with their cloud adoption and optimization journey to improve their business outcomes. In his spare time, he enjoys tennis and photography.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/c4001ebe24164038b523de5ba522a843_image.png\" alt=\"image.png\" /> <strong>Neelam Koshiya</strong> is an enterprise solution architect at AWS. Her current focus is to help enterprise customers with their cloud adoption journey for strategic business outcomes. In her spare time, she enjoys reading and being outdoors.</p>\n"}