Define customized permissions in minutes with Amazon SageMaker Role Manager

Define customized permissions in minutes with Amazon SageMaker Role Manager


Administrators of machine learning (ML) workloads are focused on ensuring that users are operating in the most secure manner, striving towards a principal of least privilege design. They have a wide variety of personas to account for, each with their own unique sets of needs, and building the right sets of permissions policies to meet those needs can sometimes be an inhibitor to agility. In this post, we look at how to use Amazon SageMaker Role Manager to quickly build out a set of persona-based roles that can be further customized to your specific requirements in minutes, right on the Amazon SageMaker console.

Role Manager offers predefined personas and ML activities combined with a wizard to streamline your permission generation process, allowing your ML practitioners to perform their responsibilities with the minimal necessary permissions. If you require additional customization, SageMaker Role Manager allows you to specify networking and encryption permissions for Amazon Virtual Private Cloud (Amazon VPC) resources and AWS Key Management Service (AWS KMS) encryption keys, and attach your custom policies.

In this post, you walk through how to use SageMaker Role Manager to create a data scientist role for accessing Amazon SageMaker Studio, while maintaining a set of minimal permissions to perform their necessary activities.

Solution overview

In this walkthrough, you perform all the steps to grant permissions to an ML administrator, create a service role for accessing required dependencies for building and training models, and create execution roles for users to assume inside of Studio to perform their tasks. If your ML practitioners access SageMaker via the AWS Management Console, you can create the permissions to allow access or grant access through IAM Identity Center (Successor to AWS Single Sign-On).

Personas

A persona is an entity that needs to perform a set of ML activities and uses a role to grant them permissions. SageMaker Role Manager provides you with a set of predefined persona templates for common use cases, or you can build your own custom persona.

There are several personas currently supported, including:

Data scientist – A persona that performs ML activities from within a SageMaker environment. They’re permitted to process Amazon Simple Storage Service (Amazon S3) data, perform experiments, and produce models.

MLOps – A persona that deals with operational activities from within a SageMaker environment. They’re permitted to manage models, endpoints, and pipelines, and audit resources.

SageMaker compute role – A persona used by SageMaker compute resources such as jobs and endpoints. They’re permitted to access Amazon S3 resources, Amazon Elastic Container Registry (Amazon ECR) repositories, Amazon CloudWatch, and other services for ML computation.

Custom role settings – This persona has no pre-selected settings or default options. It offers complete customization starting with empty settings.

For a comprehensive list of personas and additional details, refer to the persona reference of the SageMaker Role Manager Developer Guide.

ML activities

ML activities are predefined sets of permissions tailored to common ML tasks. Personas are composed of one or more ML activities to grant permissions.

For example, the data scientist persona uses the following ML activities:

Run Studio Applications – Permissions to operate within a Studio environment. Required for domain and user-profile execution roles.

Manage Experiments – Permissions to manage experiments and trials.

Manage ML Jobs – Permissions to audit, query lineage, and visualize experiments.

Manage Models – Permissions to manage SageMaker jobs across their lifecycles.

Manage Pipelines – Permissions to manage SageMaker pipelines and pipeline executions.

S3 Bucket Access – Permissions to perform operations on specified buckets.

There are many more ML activities available than the ones that are listed here. To see the full list along with template policy details, refer to the ML Activity reference of the SageMaker Role Manager Developer Guide.

The following figure demonstrates the entire scope of this post, where you first create a service execution role to allow users to PassRole for access to underlying services and then create a user execution role to grant permissions for your ML practitioners to perform their required ML activities.

Prerequisites

You need to ensure that you have a role for your ML administrator to create and manage personas, as well as the AWS Identity and Access Management (IAM) permissions for those users.

An example IAM policy for an ML administrator may look like the following code. Note that the following policy locks down Studio domain creation to VPC only. Although this is a best practice for controlling network access, you need to remove the LockDownStudioDomainCreateToVPC statement if your implementation doesn’t use a VPC-based Studio domain.

{
“Version”: “2012-10-17”,
“Statement”:
[
{
“Sid”: “LockDownStudioDomainCreateToVPC”,
“Effect”: “Allow”,
“Action”:
[
“sagemaker:CreateDomain”
],
“Resource”:
[
“arn:aws:sagemaker:<REGION>:<ACCOUNT-ID>:domain/*”
],
“Condition”:
{
“StringEquals”:
{
“sagemaker:AppNetworkAccessType”: “VpcOnly”
}
}
},
{
“Sid”: “StudioUserProfilePerm”,
“Effect”: “Allow”,
“Action”:
[
“sagemaker:CreateUserProfile”
],
“Resource”:
[
“arn:aws:sagemaker:<REGION>:<ACCOUNT-ID>:user-profile/*”
]
},
{
“Sid”: “AllowFileSystemPermissions”,
“Effect”: “Allow”,
“Action”:
[
“elasticfilesystem:CreateFileSystem”
],
“Resource”: “arn:aws:elasticfilesystem:<REGION>:<ACCOUNT-ID>:file-system/*”
},
{
“Sid”: “KMSPermissionsForSageMaker”,
“Effect”: “Allow”,
“Action”:
[
“kms:CreateGrant”,
“kms:Decrypt”,
“kms:DescribeKey”,
“kms:Encrypt”,
“kms:GenerateDataKey”,
“kms:RetireGrant”,
“kms:ReEncryptTo”,
“kms:ListGrants”,
“kms:RevokeGrant”,
“kms:GenerateDataKeyWithoutPlainText”
],
“Resource”:
[
“arn:aws:kms:<REGION>:<ACCOUNT-ID>:key/<KMS-KEY-ID>”
]
},
{
“Sid”: “AmazonSageMakerPresignedUrlPolicy”,
“Effect”: “Allow”,
“Action”:
[
“sagemaker:CreatePresignedDomainUrl”
],
“Resource”:
[
“arn:aws:sagemaker:<REGION>:<ACCOUNT-ID>:user-profile/*”
]
},
{
“Sid”: “AllowRolePerm”,
“Effect”: “Allow”,
“Action”:
[
“iam:PassRole”,
“iam:GetRole”
],
“Resource”:
[
“arn:aws:iam::<ACCOUNT-ID>:role/*”
]
},
{
“Sid”: “ListExecutionRoles”,
“Effect”: “Allow”,
“Action”:
[
“iam:ListRoles”
],
“Resource”:
[
“arn:aws:iam::<ACCOUNT-ID>:role/*”
]
},
{
“Sid”: “SageMakerApiListDomain”,
“Effect”: “Allow”,
“Action”:
[
“sagemaker:ListDomains”
],
“Resource”: “arn:aws:sagemaker:<REGION>:<ACCOUNT-ID>:domain/*”
},
{
“Sid”: “VpcConfigurationForCreateForms”,
“Effect”: “Allow”,
“Action”:
[
“ec2:DescribeVpcs”,
“ec2:DescribeSubnets”,
“ec2:DescribeSecurityGroups”
],
“Resource”: “*”
},
{
“Sid”: “KmsKeysForCreateForms”,
“Effect”: “Allow”,
“Action”:
[
“kms:DescribeKey”,
“kms:ListAliases”
],
“Resource”:
[
“arn:aws:kms:<REGION>:<ACCOUNT-ID>:key/*”
]
},
{
“Sid”: “KmsKeysForCreateForms2”,
“Effect”: “Allow”,
“Action”:
[
“kms:ListAliases”
],
“Resource”:
[
“*”
]
},
{
“Sid”: “StudioReadAccess”,
“Effect”: “Allow”,
“Action”:
[
“sagemaker:ListDomains”,
“sagemaker:ListApps”,
“sagemaker:DescribeDomain”,
“sagemaker:DescribeUserProfile”,
“sagemaker:ListUserProfiles”,
“sagemaker:EnableSagemakerServicecatalogPortfolio”,
“sagemaker:GetSagemakerServicecatalogPortfolioStatus”
],
“Resource”: “*”
},
{
“Sid”: “SageMakerProjectsSC”,
“Effect”: “Allow”,
“Action”:
[
“servicecatalog:AcceptPortfolioShare”,
“servicecatalog:ListAcceptedPortfolioShares”,
“servicecatalog:Describe*”,
“servicecatalog:List*”,
“servicecatalog:ScanProvisionedProducts”,
“servicecatalog:SearchProducts”,
“servicecatalog:SearchProvisionedProducts”,
“cloudformation:GetTemplateSummary”,
“servicecatalog:ProvisionProduct”,
“cloudformation:ListStackResources”,
“servicecatalog:AssociatePrincipalWithPortfolio”
],
“Resource”: “*”
},
{
“Action”:
[
“s3:CreateBucket”,
“s3:ListAllMyBuckets”,
“s3:GetBucketLocation”,
“s3:GetObject”,
“s3:PutObject”,
“s3:DeleteObject”,
“s3:AbortMultipartUpload”,
“s3:GetBucketCors”,
“s3:PutBucketCors”,
“s3:GetBucketAcl”,
“s3:PutObjectAcl”
],
“Effect”: “Allow”,
“Resource”:
[
“arn:aws:s3:::<S3-BUCKET-NAME>”,
“arn:aws:s3:::<S3-BUCKET-NAME>/*”
]
}
]
}

Create a service role for passing to jobs and endpoints

When creating roles for your ML practitioners to perform activities in SageMaker, they need to pass permissions to an service role that has access to manage the underlying infrastructure. This service role can be reused, and doesn’t need to be created for every use case. In this section, you create a service role and then reference it when you create your other personas via PassRole. If you already have an appropriate service role, you can use it instead of creating another one.

On the SageMaker console, choose Getting Started in the navigation bar.
Under Configure role, choose Create a role.

For Role name suffix, give your role a name, which becomes the suffix of the IAM role name created for you. For this post, we enter SageMaker-demoComputeRole.
Choose SageMaker Compute Role as your persona.
Optionally, configure the networking and encryption settings to use your desired resources.
Choose Next.

In the Configure ML activities section, you can see that the ML activity for Access Required AWS Services is already preselected for the SageMaker Compute Role persona.
Because the Access Required AWS Services ML activity is selected, further options appear.
Enter the appropriate S3 bucket ARNs and Amazon ECR ARNs that this service role will be able to access.
You can add multiple values by choosing Add in each section.
After you have filled in the required values, choose Next.

In the Add additional policies & tags section, choose any other policies your service role might need.
Choose Next.
In the Review role section, verify that your configuration is correct, then choose Submit.
The last thing you need to do for the service role is note down the role ARN so you can use it later in your data scientist persona role creation process.
To view the role in IAM, choose Go to Role in the success banner or alternatively search for the name you gave your service role persona on the IAM console.

On the IAM console, note the role’s ARN in the ARN section.

You enter this ARN later when creating your other persona-based roles.

Create an execution role for data scientists

Now that you have created the base service roles for your other personas to use, you can create your role for data scientists.

On the SageMaker console, choose Getting Started in the navigation bar.
Under Configure role, choose Create a role.
For Role name suffix, give your role a name, for example, SageMaker-dataScientistRole.
Note that this resulting name needs to be unique across your existing roles, or persona creation will fail.
Optionally, add a description.
Choose a base persona template to give your persona a baseline set of ML activities. In this example, we choose Data Scientist.
Optionally, in the Network setup section, specify the specific VPC subnets and security groups that the persona can access for resources that support them.
In the Encryption setup, you can optionally choose one or more data encryption and volume encryption keys for services that support encryption at rest.
After you have completed customizing your persona, choose Next.

In the Configure ML activities section, one or more ML activities are pre-selected based on your baseline persona template.
In this section, you can add or remove additional ML activities to tailor this role to your specific use case.

Certain ML activities require additional information to complete the role setup. For example, selecting the S3 Bucket Access ML activity requires you to specify a list of S3 buckets to grant access to.Other ML activities may require a PassRoles entry to allow this persona to pass its permissions to a service role to perform actions on behalf of the persona. In our example, the Manage ML Jobs ML activity requires a PassRoles entry.
Enter the role ARN for the service role you created earlier.
You can add multiple entries by choosing Add, which creates an array of the specified values in the resulting role.

After you have selected all the appropriate ML activities and supplied the necessary values, choose Next.
In the Add additional policies section, choose any other policies your execution role might need. You can also add tags to your execution role.
Choose Next.
In the Review Role section, verify that the persona configuration details are accurate, then choose Submit.

View and add final customizations to your new role

After submitting your persona, you can go to the IAM console and see the resulting role and policies that were created for you, as well as make further modifications. To get to the new role in IAM, choose Go to role in the success banner.

On the IAM console, you can view your newly created role along with the attached policies that map the ML activities you selected in Role Manager. You can change the existing policies here by selecting the policy and editing the document. This role can also be recreated via Infrastructure as Code (IaC) by simply taking the contents of the policy documents and inserting them into your existing solution.

Link the new role to a user

In order for your users to access Studio, they need to be associated with the user execution role you created (in this example, based on the data scientist persona). The method of associating the user with the role varies based on the authentication method you set up for your Studio domain, either IAM or IAM Identity Center. You can find the authentication method under the Domain section in the Studio Control Panel, as shown in the following screenshots.


Depending on your authentication method, proceed to the appropriate subsection.

Access Studio via IAM

Note that if you’re using the IAM Identity Center integration with Studio, the IAM role in this section isn’t necessary. Proceed to the next section.

SageMaker Role Manager creates execution roles for access to AWS services. To allow your data scientists to assume their given persona via the console, they require a console role to get to the Studio environment.

The following example role gives the necessary permissions to allow a data scientist to access the console and assume their persona’s role inside of Studio:

{
“Version”: “2012-10-17”,
“Statement”:
[
{
“Sid”: “DescribeCurrentDomain”,
“Effect”: “Allow”,
“Action”: “sagemaker:DescribeDomain”,
“Resource”: “arn:aws:sagemaker:<REGION>:<ACCOUNT-ID>:domain/<STUDIO-DOMAIN-ID>
},
{
“Sid”: “RemoveErrorMessagesFromConsole”,
“Effect”: “Allow”,
“Action”:
[
“servicecatalog:ListAcceptedPortfolioShares”,
“sagemaker:GetSagemakerServicecatalogPortfolioStatus”,
“sagemaker:ListModels”,
“sagemaker:ListTrainingJobs”,
“servicecatalog:ListPrincipalsForPortfolio”,
“sagemaker:ListNotebookInstances”,
“sagemaker:ListEndpoints”
],
“Resource”: “*”
},
{
“Sid”: “RequiredForAccess”,
“Effect”: “Allow”,
“Action”:
[
“sagemaker:ListDomains”,
“sagemaker:ListUserProfiles”
],
“Resource”: “*”
},
{
“Sid”: “CreatePresignedURLForAccessToDomain”,
“Effect”: “Allow”,
“Action”: “sagemaker:CreatePresignedDomainUrl”,
“Resource”: “arn:aws:sagemaker:<REGION>:<ACCOUNT-ID>:user-profile/<STUDIO-DOMAIN-ID>/<PERSONA_NAME>
}
]
}

The statement labeled RemoveErrorMessagesFromConsole can be removed without affecting the ability to get into Studio, but will result in API errors on the console UI.

Sometimes administrators give access to the console for ML practitioners to debug issues with their Studio environment. In this scenario, you want to grant additional permissions to view CloudWatch and AWS CloudTrail logs.

The following code is an example of a read-only CloudWatch Logs access policy:

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Action”: [
“logs:Describe*”,
“logs:Get*”,
“logs:List*”,
“logs:StartQuery”,
“logs:StopQuery”,
“logs:TestMetricFilter”,
“logs:FilterLogEvents”
],
“Effect”: “Allow”,
“Resource”: “*”
}
]
}

For additional information on CloudWatch Logs policies, refer to Customer managed policy examples.

The following code is an example read-only CloudTrail access policy:

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“cloudtrail:Get*”,
“cloudtrail:Describe*”,
“cloudtrail:List*”,
“cloudtrail:LookupEvents”
],
“Resource”: “*”
}
]
}

For more details and example policies, refer to Identity and Access Management for AWS CloudTrail.

In the Studio Control Panel, choose Add User to create your new data scientist user.
For Name, give your user a name.
For Default execution role, choose the persona role that you created earlier.
Choose Next.

Choose the appropriate Jupyter Lab version, and whether to enable Amazon SageMaker JumpStart and SageMaker project templates.
Choose Next.
This post assumes you’re not using RStudio, so choose Next again to skip RStudio configuration.
Choose whether to enable Amazon SageMaker Canvas support, and additionally whether to allow for time series forecasting in Canvas.
Choose Submit.
You can now see your new data science user in the Studio Control Panel.
To test this user, on the Launch app menu, choose Studio.
This redirects you to the Studio console as the selected user with their persona’s permissions.

Access Studio via IAM Identity Center

Assigning IAM Identity Center users to execution roles requires them to first exist in the IAM Identity Center directory. If they don’t exist, contact your identity administrator or refer to Manage identities in IAM Identity Center for instructions.

Note that in order to use the IAM Identity Center authentication method, its directory and your Studio domain must be in the same AWS Region.

To assign IAM Identity Center users to your Studio domain, choose Assign users and Groups in the Studio Control Panel.
Select your data scientist user, then choose Assign users and groups.

After the user has been added to the Studio Control panel, choose the user to open the user details screen.

On the User details page, choose Edit.
On the Edit user profile page, under General settings, change the Default execution role to match the user execution role you created for your data scientists.
Choose Next.

Choose Next through the rest of the settings pages, then choose Submit to save your changes.

Now, when your data scientist logs into the IAM Identity Center portal, they will see a tile for this Studio domain. Choosing that tile logs them in to Studio with the user execution role you assigned to them.

Test your new persona

After you’re logged in to Studio, you can use the following example notebook to validate the permissions that you granted to your data science user.

You can observe that the data scientist user can only perform the actions in the notebook that their role has been permitted. For example:

The user is blocked from running jobs without VPC or AWS KMS configuration, if the role were customized to do so
The user only has access to Amazon S3 resources if the role had the ML activity included
The user is only able to deploy endpoints if the role had the ML activity included

Clean up

To clean up the resources you created in this walkthrough, complete the following steps:

Remove the mapping of your new role to your users:

If using Studio with IAM, delete any new Studio users you created.
If using Studio with IAM Identity Center, detach the created execution role from your Studio users.

On the IAM console, find your user execution role and delete it.
On the IAM console, find your service role and delete it.
If you created a new role for an ML administrator:

Log out of your account as the ML administrator role, and back in as another administrator that has IAM permissions.
Delete the ML administrator role that you created.

Conclusion

Until recently, in order to build out SageMaker roles with customized permissions, you had to start from scratch. With the new SageMaker Role Manager, you can use the combination of personas, pre-built ML activities, and custom policies to quickly generate customized roles in minutes. This allows your ML practitioners to start working in SageMaker faster.

To learn more about how to use SageMaker Role Manager, refer to the SageMaker Role Manager Developer Guide.

About the authors

Giuseppe Zappia is a Senior Solutions Architect at AWS, with over 20 years of experience in full stack software development, distributed systems design, and cloud architecture. In his spare time, he enjoys playing video games, programming, watching sports, and building things.

Ram Vittal is a Principal ML 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 riding motorcycle, playing tennis, and photography.

Arvind Sowmyan is a Senior Software Development Engineer on the SageMaker Model Governance team where he specializes in building scalable webservices with a focus on enterprise security. Prior to this, he worked on the Training Jobs platform where he was a part of the SageMaker launch team. In his spare time, he enjoys illustrating comics, exploring virtual reality and tinkering with large language models.

Ozan Eken is a Senior Product Manager at Amazon Web Services. He is passionate about building governance products in Machine Learning for enterprise customers. Outside of work, he likes exploring different outdoor activities and watching soccer.

Read More


Generated by Feedzy