Be considerate of users in an enterprise environment with cdk bootstrap

[clcpolevaulter]

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

[rix0rrr]

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]

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

[rix0rrr]

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]

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

[SomayaB]

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