Amazon SageMaker
Developer Guide

Using Identity-based Policies (IAM Policies) for Amazon SageMaker

This topic provides examples of identity-based policies that demonstrate how an account administrator can attach permissions policies to IAM identities (that is, users, groups, and roles) and thereby grant permissions to perform operations on Amazon SageMaker resources.

Important

We recommend that you first review the introductory topics that explain the basic concepts and options available to manage access to your Amazon SageMaker resources. For more information, see Overview of Managing Access Permissions to Your Amazon SageMaker Resources.

The following is an example of a basic permissions policy:

{ "Version": "2012-10-17", "Statement": [{ "Sid": "AllowCreate-Describe-Delete-Models", "Effect": "Allow", "Action": [ "sagemaker:CreateModel", "sagemaker:DescribeModel", "sagemaker:DeleteModel"], "Resource": "*" } ], "Statement": [{ "Sid": "AdditionalIamPermission", "Effect": "Allow", "Action": [ "iam:PassRole"], "Resource": "arn:aws:iam::account-id:role/role-name" } ] }

The policy has two statements:

  • The first statement grants permission for three Amazon SageMaker actions (sagemaker:CreateModel, sagemaker:DescribeModel, and sagemaker:DeleteModel) within an Amazon SageMaker notebook instance. Using the wildcard character (*) as the resource grants universal permissions for these actions across all AWS Regions and models owned by this account.

  • The second statement grants permission for the iam:PassRole action, which is needed for the Amazon SageMaker action sagemaker:CreateModel, which is allowed by the first statement.

The policy doesn't specify the Principal element because in an identity-based policy you don't specify the principal who gets the permission. When you attach the policy to a user, the user is the implicit principal. When you attach a permissions policy to an IAM role, the principal identified in the role's trust policy gets the permissions.

For a table showing all of the Amazon SageMaker API operations and the resources that they apply to, see Amazon SageMaker API Permissions: Actions, Permissions, and Resources Reference.

Permissions Required to Use the Amazon SageMaker Console

The permissions reference table lists the Amazon SageMaker API operations and shows the required permissions for each operation. For more information about Amazon SageMaker API operations, see Amazon SageMaker API Permissions: Actions, Permissions, and Resources Reference.

To use the Amazon SageMaker console, you need to grant permissions for additional actions. Specifically, the console needs permissions that allow the ec2 actions to display subnets, VPCs, and security groups. Optionally, the console needs permission to create execution roles for tasks such as CreateNotebook, CreateTrainingJob, and CreateModel. Grant these permissions with the following permissions policy:

{ "Version": "2012-10-17", "Statement": [ // Populate customer VPCs, Subnets, and Security Groups for CreateNotebookInstance form // These permissions needed to create the notebook instance in the console { "Sid": "CreateNotebookInstanceForm", "Effect": "Allow", "Action": [ "ec2:DescribeVpcs", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource": "*" }, // Create execution roles for CreateNotebookInstance, CreateTrainingJob, and CreateModel // Needed if creating an IAM role (for example, as part of creating a notebook instance) { "Sid": "CreateExecutionRoles", "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:CreatePolicy", "iam:AttachRolePolicy" ], "Resource": "*" } ] }

AWS Managed (Predefined) Policies for Amazon SageMaker

AWS addresses many common use cases by providing standalone IAM policies that are created and administered by AWS. These AWS managed policies grant necessary permissions for common use cases so that you can avoid having to investigate which permissions are needed. For more information, see AWS Managed Policies in the IAM User Guide.

The following AWS managed policies, which you can attach to users in your account, are specific to Amazon SageMaker:

  • AmazonSageMakerReadOnly – Grants read-only access to Amazon SageMaker resources.

  • AmazonSageMakerFullAccess – Grants full access to Amazon SageMaker resources and the supported operations. (This does not provide unrestricted S3 access, but supports buckets/objects with specific sagemaker tags.)

The following AWS managed policies can also be attached to users in your account:

  • AdministratorAccess – Grants all actions for all AWS services and for all resources in the account.

  • DataScientist – Grants a wide range of permissions to cover most of the use cases (primarily for analytics and business intelligence) encountered by data scientists.

You can review these permissions policies by signing in to the IAM console and searching for them.

You can also create your own custom IAM policies to allow permissions for Amazon SageMaker actions and resources as you need them. You can attach these custom policies to the IAM users or groups that require them.

Control Access to Amazon SageMaker Resources by Using Tags

Control access to groups of Amazon SageMaker resources by attaching tags to the resources and specifying ResourceTag conditions in IAM policies. For example, suppose you've defined two different IAM groups, named DevTeam1 and DevTeam2, in your AWS account. Suppose also that you've created 10 notebook instances, 5 of which are used for one project, and 5 of which are used for a second project. You want to allow members of DevTeam1 to make API calls on notebook instances used for the first project, and members of DevTeam2 to make API calls on notebook instances used for the second project. You can control access to API calls by completing the following steps:

  1. Add a tag with the key Project and value A to the notebook instances used for the first project. For information about adding tags to Amazon SageMaker resources, see AddTags.

  2. Add a tag with the key Project and value B to the notebook instances used for the second project.

  3. Create an IAM policy with a ResourceTag condition that denies access to the notebook instances used for the second project, and attach that policy to DevTeam1. The following is an example of a policy that denies all API calls on any notebook instance that has a tag with a key of Project and a value of B:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sagemaker:*", "Resource": "*" }, { "Effect": "Deny", "Action": "sagemaker:*", "Resource": "*", "Condition": { "StringEquals": { "sagemaker:ResourceTag/Project": "B" } } }, { "Effect": "Deny", "Action": [ "sagemaker:CreateTags", "sagemaker:DeleteTags" ], "Resource": "*" } ] }

    For information about creating IAM policies and attaching them to identities, see Controlling Access Using Policies in the AWS Identity and Access Management User Guide.

  4. Create an IAM policy with a ResourceTag condition that denies access to the notebook instances used for the first project, and attach that policy to DevTeam2. The following is an example of a policy that denies all API calls on any notebook instance that has a tag with a key of Project and a value of A:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "sagemaker:*", "Resource": "*", "Condition": { "StringEquals": { "sagemaker:ResourceTag/Project": "A" } } }, { "Effect": "Deny", "Action": [ "sagemaker:CreateTags", "sagemaker:DeleteTags" ], "Resource": "*" } ] }

Note

You cannot use tags to either allow or deny calls to InvokeEndpoint

Require the Presence or Absence of Tags for API Calls

Require the presence or absence of specific tags or specific tag values by using RequestTag condition keys in an IAM policy. For example, if you want to require that every endpoint created by any member of an IAM group to be created with a tag with the key environment and value dev, create a policy as follows:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "sagemaker:CreateEndpoint", "Resource": [ "arn:aws:sagemaker:*:*:endpoint/*" ] { "Effect": "Allow", "Action": "sagemaker:CreateEndpoint", "Resource": [ "arn:aws:sagemaker:*:*:endpoint/*" ], "Condition": { "StringEquals": { "aws:RequestTag/environment": "dev" } } } ] }

Using Tags with Hyperparameter Tuning Jobs

You can add tags to a hyperparameter tuning job when you create the tuning job by specifying the tags as the Tags parameter when you call CreateHyperParameterTuningJob. If you do this, the tags you specify for the hyperparameter tuning job are also added to all training jobs that the hyperparameter tuning job launches.

If you add tags to a hyperparameter tuning job by calling AddTags, the tags you add are also added to any training jobs that the hyperparameter tuning job launches after you call AddTags, but are not added to training jobs the hyperparameter tuning jobs launched before you called AddTags. Similarly, when you remove tags from a hyperparameter tuning job by calling DeleteTags, those tags are not removed from training jobs that the hyperparameter tuning job launched previously. Because of this, the tags associated with training jobs can be out of sync with the tags associated with the hyperparameter tuning job that launched them. If you use tags to control access to a hyperparameter tuning job and the training jobs it launches, you might want to keep the tags in sync. To make sure the tags associated with training jobs stay sync with the tags associated with the hyperparameter tuning job that launched them, first call ListTrainingJobsForHyperParameterTuningJob for the hyperparameter tuning job to get a list of the training jobs that the hyperparameter tuning job launched. Then, call AddTags or DeleteTags for the hyperparameter tuning job and for each of the training jobs in the list of training jobs to add or delete the same set of tags for all of the jobs. The following Python example demonstrates this:

tuning_job_arn = smclient.describe_hyper_parameter_tuning_job(HyperParameterTuningJobName='MyTuningJob')['HyperParameterTuningJobArn'] smclient.add_tags(ResourceArn=tuning_job_arn, Tags=[{'Key':'Env', 'Value':'Dev'}]) training_jobs = smclient.list_training_jobs_for_hyper_parameter_tuning_job( HyperParameterTuningJobName='MyTuningJob')['TrainingJobSummaries'] for training_job in training_jobs: time.sleep(1) # Wait for 1 second between calls to avoid being throttled smclient.add_tags(ResourceArn=training_job['TrainingJobArn'], Tags=[{'Key':'Env', 'Value':'Dev'}])