# Monitoring user resource access from SageMaker AI Studio Classic with sourceIdentity Monitoring individual user access With Amazon SageMaker Studio Classic, you can monitor user resource access. To view resource access activity, you can configure AWS CloudTrail to monitor and record user activities by following the steps in [Log Amazon SageMaker API Calls with AWS CloudTrail](https://docs.aws.amazon.com/sagemaker/latest/dg/logging-using-cloudtrail.html). However, the AWS CloudTrail logs for resource access only list the Studio Classic execution IAM role as the identifier. This level of logging is enough to audit user activity when each user profile has a distinct execution role. However, when a single execution IAM role is shared between several user profiles, you can't get information about the specific user that accessed the AWS resources.  You can get information about which specific user performed an action in an AWS CloudTrail log when using a shared execution role, using the `sourceIdentity` configuration to propagate the Studio Classic user profile name. For more information about source identity, see [Monitor and control actions taken with assumed roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_monitor.html). To turn `sourceIdentity` on or off for your CloudTrail logs, see [Turn on sourceIdentity in CloudTrail logs for SageMaker AI Studio Classic](monitor-user-access-how-to.md). ## Considerations when using sourceIdentity When you make AWS API calls from Studio Classic notebooks, SageMaker Canvas, or Amazon SageMaker Data Wrangler, the `sourceIdentity` is only recorded in CloudTrail if those calls are made using the Studio Classic [execution role](sagemaker-roles.md) session or any [chained role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-role-chaining) from that session. When these API calls invoke other services to perform additional operations, `sourceIdentity` logging depends on the specific implementation of the invoked services. + Amazon SageMaker Training and Processing: When you create a job using the training feature or the processing feature, the job creation API calls ingest the `sourceIdentity` that exists in the session. As a result, any AWS API calls made from these jobs record the `sourceIdentity` in the CloudTrail logs. + Amazon SageMaker Pipelines: When you create jobs using automated CI/CD pipelines, `sourceIdentity` propagates downstream and can be viewed in the CloudTrail logs. + Amazon EMR: When connecting to Amazon EMR from Studio Classic using [runtime roles](studio-notebooks-emr-cluster-rbac.md), administrators must explicitly [set the PropagateSourceIdentity field](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-steps-runtime-roles.html). This ensures that Amazon EMR applies the `sourceIdentity` from the calling credentials to a job or query session. The `sourceIdentity` is then recorded in CloudTrail logs. **Note** The following exceptions apply when using `sourceIdentity`. SageMaker Studio Classic shared spaces do not support `sourceIdentity` passthrough. AWS API calls made from SageMaker AI shared spaces do not record `sourceIdentity` in CloudTrail logs. If AWS API calls are made from sessions that are created by users or other services and the sessions are not based on the Studio Classic execution role session, then the `sourceIdentity` is not recorded in CloudTrail logs. # Turn on sourceIdentity in CloudTrail logs for SageMaker AI Studio Classic Turn on sourceIdentity for Studio Classic With Amazon SageMaker Studio Classic, you can monitor user resource access. However, the AWS CloudTrail logs for resource access only list the Studio Classic execution IAM role as the identifier. When a single execution IAM role is shared between several user profiles, you must use the `sourceIdentity` configuration to get information about the specific user that accessed the AWS resources. The following topics explain how to turn on or off the `sourceIdentity` configuration. **Topics** + [ ## Prerequisites ](#monitor-user-access-prereq) + [ ## Turn on sourceIdentity ](#monitor-user-access-enable) + [ ## Turn off sourceIdentity ](#monitor-user-access-disable) ## Prerequisites + Install and configure the AWS Command Line Interface following the steps in [Installing or updating the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). + Ensure that Studio Classic users in your domain don’t have a policy that allows them to update or modify the domain.  + To turn on or turn off `sourceIdentity` propagation, all apps in the domain must be in the `Stopped` or `Deleted` state. For more information about how to stop and shut down apps, see [Shut down and Update Studio Classic Apps](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-tasks-update-apps.html). + If source identity propagation is turned on, all execution roles must have the following trust policy permissions:  + Any role that the domain's execution role assumes must have the `sts:SetSourceIdentity` permission in the trust policy. If this permission is missing, your actions fail with `AccessDeniedException` or `ValidationError` when you call the job creation API. The following example trust policy includes the `sts:SetSourceIdentity` permission. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "sagemaker.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ] } ] } ``` ------ + When you assume a role with another role, called role chaining, do the following: + Permissions for `sts:SetSourceIdentity` are required in both the permissions policy of the principal that is assuming the role, and in the role trust policy of the target role. Otherwise, the assume role operation will fail. + This role chaining can happen in Studio Classic or any other downstream service, such as Amazon EMR. For more information about role chaining, see [Roles terms and concepts](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html). ## Turn on sourceIdentity The ability to propagate the user profile name as the `sourceIdentity` in Studio Classic is turned off by default. To enable the ability to propagate the user profile name as the `sourceIdentity`, use the AWS CLI during domain creation and domain update. This feature is enabled at the domain level and not at the user profile level. After you enable this configuration, administrators can view the user profile in the AWS CloudTrail log for the service accessed. The user profile is given as the `sourceIdentity` value in the `userIdentity` section. For more information about using AWS CloudTrail logs with SageMaker AI, see [Log Amazon SageMaker AI API Calls with AWS CloudTrail](https://docs.aws.amazon.com/sagemaker/latest/dg/logging-using-cloudtrail.html). You can use the following code to enable the propagation of the user profile name as the `sourceIdentity` during domain creation using the `create-domain` API. ``` create-domain --domain-name --auth-mode --default-user-settings --subnet-ids --vpc-id [--tags ] [--app-network-access-type ] [--home-efs-file-system-kms-key-id ] [--kms-key-id ] [--app-security-group-management ] [--domain-settings "ExecutionRoleIdentityConfig=USER_PROFILE_NAME"] [--cli-input-json ] [--generate-cli-skeleton ] ``` You can enable the propagation of the user profile name as the `sourceIdentity` during domain update using the `update-domain` API. To update this configuration, all apps in the domain must be in the `Stopped` or `Deleted` state. For more information about how to stop and shut down apps, see [Shut down and Update Studio Classic Apps](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-tasks-update-apps.html). Use the following code to enable the propagation of the user profile name as the `sourceIdentity`. ``` update-domain --domain-id [--default-user-settings ] [--domain-settings-for-update "ExecutionRoleIdentityConfig=USER_PROFILE_NAME"] [--cli-input-json ] [--generate-cli-skeleton ] ``` ## Turn off sourceIdentity You can also turn off the propagation of the user profile name as the `sourceIdentity` using the AWS CLI. This occurs during domain update by passing the `ExecutionRoleIdentityConfig=DISABLED` value for the `--domain-settings-for-update` parameter as part of the `update-domain` API call. In the AWS CLI, use the following code to disable the propagation of the user profile name as the `sourceIdentity`. ``` update-domain --domain-id [--default-user-settings ] [--domain-settings-for-update "ExecutionRoleIdentityConfig=DISABLED"] [--cli-input-json ] [--generate-cli-skeleton ] ```