Tracking AssumeRole activities

Hello there,

My understanding from the description of your question is that you are noticing assumed role access KeyID is different when performing action against S3 using AWS CLI vs AWS console.

The variance in the access KeyID of an assumed role arises when accessing Amazon S3 via the AWS Management Console compared to assuming the same role for S3 access through the AWS Command Line Interface (CLI). This distinction can be attributed to how AWS administers temporary security credentials and sessions. Several factors contribute to this differentiation

Temporary Credentials: Upon role assumption, temporary security credentials, which encompass access keys, are provided. For security reasons, these credentials are periodically rotated. Upon each role assumption, a fresh set of temporary credentials may be issued, leading to a distinct KeyID.

Console vs. CLI Sessions: The AWS Management Console and AWS CLI operate as discrete tools, and they may manage temporary credentials differently. The console might establish an autonomous session with temporary credentials, while the CLI creates its own session when executing a command. Consequently, these sessions might possess varying access keys and KeyIDs.

Session Duration and Expiry: Temporary credentials have a predetermined lifespan before they expire. Assuming the role at differing intervals through the console and CLI might generate distinct sets of credentials due to session duration.

Role Assumption Configuration: The configuration and method of role assumption within both the console and CLI can impact the generation and application of temporary credentials.

Cross-Account Access: If the assumed role involves access across different AWS accounts, the access keys could inherently diverge since they pertain to distinct accounts.

Credential Rotation: AWS periodically rotates temporary credentials for security enhancement. The rotation procedure might diverge between the console and the CLI.

In order to see consistency in access KeyID of the assumed role, AWS introduced the concept of "source identity" in CloudTrail to help you monitor actions taken with assumed roles more effectively. Source identity allows you to track the original caller (source) of an action when a user or service assumes a role. This is particularly useful for tracing actions back to their origin.

Administrators can configure roles to require identities to pass a custom string that identifies the person or application that is performing actions in AWS. This identity information is stored as the source identity in AWS CloudTrail. When the administrator reviews activity in CloudTrail, they can view the source identity information to determine who or what performed actions with assumed role sessions. Please refer to AWS documentation Monitor and control actions taken with assumed roles for guidance on how it can be configured and utilized.

To ensure a consistent experience and understanding of the behavior, it's a good practice to consult AWS documentation and verify the current behavior of role assumption, temporary credentials, and session management for both the console and the CLI. You can refer to the AWS IAM documentation for more details on how role assumption and temporary credentials work

Please let me know if this help.

Thanks

References:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_monitor.html#id_credentials_temp_control-access_monitor-setup

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html