Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assumed Role - Randomized UserId gntd-<random-suffix> #614

Open
Siushaga opened this issue Feb 29, 2024 · 0 comments
Open

Assumed Role - Randomized UserId gntd-<random-suffix> #614

Siushaga opened this issue Feb 29, 2024 · 0 comments

Comments

@Siushaga
Copy link

I'm facing a similar issue to why PR's were implemented, such as the ones below:
#189
#469

The difference for our use case is that we use a GlobalReadOnly role in a central account that has the ability to assume a ReadOnly role in any of the AWS accounts that we own. The GlobalReadOnly (or any "single hop" role) is presenting the UserId as our Active Directory UserId, as expected. However, if a role assumption is introduced then the session name is receiving a name like "gntd-".

This layer of anonymity in CloudTrail where we can't attribute to what individual user did something will render this utility unusable for us, so I'm hopeful this is something that can be addressed.

In my ~/.aws/config file I have a profile for global-read-only that uses a credential_process to call okta-cli to process-credentials from the central account's Okta IdP and GlobalReadOnly role, while all other profiles set the role_arn to the ReadOnly role in each account along with a source_profile set to the global-read-only profile.

Doing an assume on one of the cross account read only roles works fine to get console access or temporary creds in my terminal. However, aws sts get-caller-identity shows like this
{ "UserId": "REDACTED_PRINCIPAL_ID:gtnd-2d1LCv2dD5bIlx0hzQl4gpaw2pm", "Account": "REDACTED", "Arn": "arn:aws:sts::REDACTED:assumed-role/ReadOnly/gtnd-2d1LCv2dD5bIlx0hzQl4gpaw2pm" }

Do an assume on the global-read-only profile, or any of my other more permissive profiles that don't involve cross account access and it looks correct with AD user identity.
{ "UserId": "REDACTED_PRINCIPAL_ID:AD_USER_ID", "Account": "REDACTED", "Arn": "arn:aws:sts::REDACTED:assumed-role/GlobalReadOnly/AD_USER_ID" }

We thought perhaps we needed to include sts:TagSession or sts:TransitiveTagKeys on the role's permissions, but I'm still seeing the same issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant