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

[mrgrain]

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

[richardhboyd]

I'm curious about the use-case that the existing --profile flag doesn't work. I wouldn't think you would need to address the profiles in your javascript. the --profile would be used when executing the CDK synth/deploy at the command line and the CDK App itself would be unaware of which profile is being used.

[mrgrain]

The existing --profile flag does work, but it's not native to JS/CDK and imho relatively complicated way to setup credentials this way.

In order to assume a role using profiles, one has to create a .aws/config file with the appropriate contents. This either has to be done manually or it requires installing the aws-cli tool. In many CI/CD situations, the default location in $HOME could not be used either and AWS_CONFIG_FILE would have to be set as well.

CDK already sets a precedent for this with the --ec2creds flag. This is also entirely possible with profiles, however the usefulness justifies the simplification.

tldr; I believe it's a common scenario and it shouldn't be necessary to step outside of CDK to be able to do this.

[mrgrain]

Actually, according to [master] CDK CLI Authentication Issues using profiles does not work to assume roles at all:

CDK CLI does not support using EC2/CodeBuild credentials to assume roles in profiles

If this is still true, adding the flag would be even more important.

[richardhboyd]

I’m curious bout the use-case for profiles in CodeBuild. Usually a CodeBuild Job has an attached Role that is used to perform the build task, typically if multiple roles are needed (I.e. to interact with multiple target environments) the user would create multiple Jobs with distinct roles to maintain least privilege permissions.

[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.

[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.

[deleugpn]

Quite sad to see how complex it still is to setup CDK to run from within AWS CodeBuild. I have an account that has been bootstrapped already and has multiple teams using CDK.
I'm deploying on CDK stack called my-project-codebuild-release where I create an AWS CodeBuild with a GitHub Webhook Trigger. My buildspec is suppose to run unit tests and then deploy using cdk deploy.

The IAM Role attached to CodeBuild is not authorized to assume-role the IAM CDK Deployer Role. I tried to manually stitch that together so that I could just run cdk deploy my-project-lambda-release from inside CodeBuild and even though the warning about not being able to assume role has disappeared, I still get stuck with AccessDenied for CloudFormation DescribeStack. I don't want to be forced to reproduce all CDK Deploy Role within my IAM CodeBuild Role. I just want CDK to be able to use it's own role from inside AWS CodeBuild.