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

Be considerate of users in an enterprise environment with cdk bootstrap #5798

Closed
2 tasks
clcpolevaulter opened this issue Jan 15, 2020 · 5 comments
Closed
2 tasks
Assignees
Labels
@aws-cdk/aws-iam Related to AWS Identity and Access Management closing-soon This issue will automatically close in 4 days unless further comments are made. effort/medium Medium work item – several days of effort feature-request A feature should be added or improved.

Comments

@clcpolevaulter
Copy link

In the enterprise environment I work in, we have robust solutions built up around IAM. All policy statements need to be scoped to their target resource [where possible] and managed through a centralized location. I'd like to see CDK be flexible enough to allow enterprises to create IAM resources externally.

⚠️ With out this, my company and many other enterprises with these controls will be unable to utilize CDK.

Use Case

Allow users of CDK to generate IAM Policies and Roles via a CLI that can be provisioned separately from the stack. These policies should be scoped to their target resources. This allows enterprise users to follow process and provide the CDK with the roles [and policies] ARNs created outside of CloudFormation via their enterprise controls.

Proposed Solution

cdk bootstrap should have an option that generates all required IAM Policies and Roles into a target directory. This goes for "Publishing Role" and "Deployment Action Role" describes in the design document for cdk bootstrap in addition to a "Creation Policy" that can be attached to the actor for resource creation. You should then be able to specify the role ARNs when creating the stack.

Can do, but not the Creation Policy?

If you don't provide a "Creation Policy", we need the ability to name and/or tag all the resources for proper scoping before an actor can run cdk bootstrap.

Alternative Solution

Provide managed user policies similar to ElasticBeanstalk Service Roles. This is great if the policy is intended to be attached to a role with a strict service principal instead of any role. This would still require a publishing, deployment, and creation policy and the ability to specify the ARN of the role that it was attached to separately from the bootstrap CloudFormation stack.

Other

This is an extension of #2390 and #3684.

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

This is a 🚀 Feature Request

@clcpolevaulter clcpolevaulter added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Jan 15, 2020
@SomayaB SomayaB added the @aws-cdk/aws-iam Related to AWS Identity and Access Management label Jan 15, 2020
@rix0rrr
Copy link
Contributor

rix0rrr commented Jan 21, 2020

Our standard bootstrapping solution will create roles that the majority of users will need for the majority of cases, and have default well-known names.

You will be free to NOT use our bootstrapping template, but a compatible one, having it installed whichever way you please into your target account. The only additional non-standard step you will have to do is tell the CDK app about the exact role and bucket names that got created (if they aren't the default ones).

@clcpolevaulter
Copy link
Author

This sounds great. Is this documented somewhere that I missed? Is this functionality available today?

@rix0rrr
Copy link
Contributor

rix0rrr commented Jan 23, 2020

No, this will be how it works at the conclusion of our current work on refactoring the deployment story to support deploying CDK apps via CodePipelines.

@skinny85
Copy link
Contributor

To expand a little bit on what Rico said.

In the re-vamped bootstrapping tool that you mentioned in your original post, we are deliberately moving to making the bootstrap command a very thin wrapper around simply deploying a CloudFormation template. The template has a set of parameters that will be used to customize it from the CLI, for example:

  • The TrustedPrincipals parameter is used to pass account root principals to the template that are constructed from the --trust CLI option, if it was used it.
  • The CloudFormationExecutionPolicies are the Managed Policies passed in the --cloudformation-execution-policies CLI option, if it was used.

Now, because of this strategy of "bootstrapping is simply deploying a CloudFormation template", we assume that, if you want to heavily customize bootstrapping to fit your needs, you will deploy your own template instead of using cdk bootstrap. Of course, you can base it on our template, which we will publish in a well-known location.

Does this answer your questions @clcpolevaulter ?

Thanks,
Adam

@rix0rrr rix0rrr added the effort/medium Medium work item – several days of effort label Feb 18, 2020
@SomayaB SomayaB added response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. and removed needs-triage This issue or PR still needs to be triaged. labels Mar 4, 2020
@SomayaB SomayaB added closing-soon This issue will automatically close in 4 days unless further comments are made. and removed response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. labels Mar 12, 2020
@SomayaB
Copy link
Contributor

SomayaB commented Mar 16, 2020

Closing this issue since there hasn't been a response in a while. Feel free to reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-iam Related to AWS Identity and Access Management closing-soon This issue will automatically close in 4 days unless further comments are made. effort/medium Medium work item – several days of effort feature-request A feature should be added or improved.
Projects
None yet
Development

No branches or pull requests

5 participants