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

Specify --role-arn multiple times for cross-account functionality #63

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

johnstanfield
Copy link

Suppose you have a multiple accounts with AWS Organizations deployed. You might have a Security OU with a Security account, and you might have many workload accounts. Suppose you also have various on-prem hosts that need to assume roles in the workload accounts.

Ideal scenario

In the ideal scenario, there is 1 AWS account, managed by the information security team, that contains the trust anchor(s) and Roles Anywhere profiles.

                                                         *** SECURITY OU ***                                                              *** WORKLOAD OU ***
on-prem host 1 ---\                                                                                                        /------- IAM role in workload account 1
on-prem host 2 -------->   [ trust anchor in security account ] --- > [ Roles Anywhere profile in security account] -->  ---------- IAM role in workload account 2
on-prem host n ---/                                                                                                        \------- IAM role in workload account n

Why you couldn't have the ideal scenario

The signing tool and/or IAM/STS in general do not allow cross-account pass role. So you can not create a Roles Anywhere profile for a role ARN in another account, nor can you pass a --profile-arn and --role-arn to the aws_signing_helper if those two ARNs are in different AWS accounts, as this will result in a cross-account pass role is not allowed error.

Not ideal scenario, but it works

Because the ideal scenario couldn't be had, the trust anchor and profiles have to exist in each workload account. This is cumbersome for a security team to maintain at scale.

                                             ***               REPEATED IN EACH WORKLOAD OU                    ***
on-prem host 1 -------->   [ trust anchor and Roles Anywhere profile in workload account 1 ] ---------->  IAM role in workload account 1
on-prem host 2 -------->   [ trust anchor and Roles Anywhere profile in workload account 2 ] ---------->  IAM role in workload account 2
on-prem host n -------->   [ trust anchor and Roles Anywhere profile in workload account n ] ---------->  IAM role in workload account n

What this pull request does

Perhaps it easier to explain with code examples

before

You can only use the aws_signing_helper to get credentials for one role ARN.

/path/to/aws_signing_helper credential-process \
    --certificate credential-process-data/client-cert.pem \
    --private-key credential-process-data/client-key.pem \
    --role-arn arn:aws:iam::111111111111:role/test-roles-anywhere \
    --trust-anchor-arn arn:aws:rolesanywhere:us-west-2:111111111111:trust-anchor/abcdef-012345 \
    --profile-arn arn:aws:rolesanywhere:us-west-2:111111111111:profile/fedcba-654987

after

You can specify --role_arn over and over again. The first --role-arn is used to retrieve credentials from Roles Anywhere. Subsequent --role-arn arguments pass those credentials to sts:AssumeRole to assume the next role.

/path/to/aws_signing_helper credential-process \
    --certificate credential-process-data/client-cert.pem \
    --private-key credential-process-data/client-key.pem \
    --role-arn arn:aws:iam::111111111111:role/test-roles-anywhere \
    --role-arn arn:aws:iam::222222222222:role/desired-role \                                       # THIS!
    --trust-anchor-arn arn:aws:rolesanywhere:us-west-2:111111111111:trust-anchor/abcdef-012345 \
    --profile-arn arn:aws:rolesanywhere:us-west-2:111111111111:profile/fedcba-654987

bigger example

You can specify --role_arn over and over again, and you can override the default sts:AssumeRole role-session-name of my-session

/path/to/aws_signing_helper credential-process \
    --certificate credential-process-data/client-cert.pem \
    --private-key credential-process-data/client-key.pem \
    --role-arn arn:aws:iam::111111111111:role/test-roles-anywhere \
    --role-arn arn:aws:iam::222222222222:role/intermediate-role \     # the credentials retrieved for the first --role-arn are used to retrieve credentials for this role arn
    --role-session-name my-first-session
    --role-arn arn:aws:iam::222222222222:role/final-role \            # the credentials retrieved for the second --role-arn are used to retrieve credentials for this role arn
    --role-session-name my-second-session
    --trust-anchor-arn arn:aws:rolesanywhere:us-west-2:111111111111:trust-anchor/abcdef-012345 \
    --profile-arn arn:aws:rolesanywhere:us-west-2:111111111111:profile/fedcba-654987

Summary

  • if you specify --role-arn one time, then the credential helper works as it always did
  • if you specify --role-arn more than once, then the credential helper works as it always did for the first --role-arn, then it does sts:Assume role for the subsequent --role-arn arguments
  • the result is the same: the output of the credential helper is a JSON object containing a Version, AccessKeyId, SecretAccessKey, SessionToken, and Expiration

John Stanfield added 4 commits February 6, 2024 14:20
…fied multiple times, and its corresponding variable is now an array
…arn arguments, using the credentials of each assumed role to assume the next role
…d multiple times, so that each additional role-arn argument can assume a role with the specified session name
@johnstanfield johnstanfield changed the title Role arns Specify --role-arn multiple times for cross-account functionality Feb 7, 2024
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

Successfully merging this pull request may close these issues.

1 participant