-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
CLI supports assuming a different role locally via --assume-role-arn #8272
Comments
--assume-role-arn
--assume-role-arn
I'm curious about the use-case that the existing |
The existing In order to assume a role using profiles, one has to create a CDK already sets a precedent for this with the 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. |
Actually, according to [master] CDK CLI Authentication Issues using profiles does not work to assume roles at all:
If this is still true, adding the flag would be even more important. |
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. |
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. |
For anyone else trying to plug CDK into an automated build environment, here's my solution:
It requires the standard |
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. 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 |
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:
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 toChainableTemporaryCredentials
which would be used to configure the SDK.This is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: