CLI supports assuming a different role locally via --assume-role-arn

To add a new command line flag --assume-role-arn [role-arn] which will assume the given role locally before executing any commands.

This should be semantically equivalent to setting the following configuration when using the aws-sdk:

AWS.config.credentials = new AWS.ChainableTemporaryCredentials({
  params: {RoleArn: '...'}
});

It would be expected to work with all variations of --ec2creds.

Use Case

Sometimes the current credentials are not enough to execute CDK. This is different from --role-arn which happens on ChangeSet execution. However CDK needs to do things before that (e.g. uploading assets).

This is also supported by the aws-cli via profiles, which proves the use case. However working with cli profiles from the JavaScript world is painful (even though support got better) and is more complicated to automate in CI/CD environments.

Terraform has a similar option: https://www.terraform.io/docs/providers/aws/index.html#assume_role

Proposed Solution

See above. We need a new cli flag. Somewhere in aws-auth the value would need to be passed in to ChainableTemporaryCredentials which would be used to configure the SDK.

• [x ] 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[danwashusen]

For anyone else trying to plug CDK into an automated build environment, here’s my solution:

    - ASSUMED_FOLE=$(aws sts assume-role --role-arn "$AWS_ROLE_ARN" --role-session-name $GITLAB_USER_LOGIN --output json)
    - export AWS_ACCESS_KEY_ID=$(echo $ASSUMED_FOLE | jq -r .Credentials.AccessKeyId)
    - export AWS_SECRET_ACCESS_KEY=$(echo $ASSUMED_FOLE | jq -r .Credentials.SecretAccessKey)
    - export AWS_SESSION_TOKEN=$(echo $ASSUMED_FOLE | jq -r .Credentials.SessionToken)
    - cdk bootstrap
    - cdk deploy foobar

It requires the standard AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to be defined for the initial sts call.

[mrgrain]

I cannot speak for CodeBuild, as we are using Jenkins running on an EC2. I can only assume there would be a similar use case to the one we have. In any case, apparently it was warranted that @rix0rrr included the quoted section into the linked master issue.

For Jenkins/EC2 the issue is that agent instances run on a single shared EC2 with a single shared instance role. In order to maintain least privilege permissions, we have each stage of every Job assume permissions appropriate to what the stage is doing. This could be assuming a role on AWS to deploy (multiple) CDK stacks or upload a file to S3, but also credentials to install private npm packages. Again, I’m not actively using CodeBuild, but this might be equivalent to different CodeBuild phases requiring different roles.