[security] Why is the CDK using the CF service role?

[erikerikson]

CDK bootstrapping, by default, sets up a CF execution role that has Administrator rights meaning that anyone who can deploy to CF will have escalation capabilities in a bootstrapped account. Further, once a stack has been deployed with that role, it will always thereafter use it.

This seems to produce a glaring persistent escalation path. Despite guidance to customize these rights, you have to be fairly invested before it is worth digging in at which point you would be in a bind if any deployed stacks are depended upon.

What is the reasoning behind the use of the service role? Why was there a switch from using the rights of the deploying entity?

[erikerikson]

For anyone that stumbles upon this, you might find CliCredentialsStackSynthesizer to be interesting. It forgoes the use of the CF execution role instead using the role of the caller (though you should read that documentation).

[peterwoodworth]

@github-actions proposed-answer This permission set is broad on purpose - CloudFormation will need to do many, unspecified things in your account involving lots of different services when deploying stacks. It's simplest and easiest for customers to get up and running to have the default execution role be one that won't block use cases by default.

As the documentation you linked states, it's not that hard to change the service role - Using our stack synthesizers in CDK makes it easy. Additionally, you could also change the permissions the role grants.

As for why we require bootstrapping by default - it allows for much more fine-grained control regarding who can assume the deployment role, and what cloudformation has access to perform in the account through the execution role. It also makes it easier for our asset uploading process to go smoothly if bootstrapped using the modern template. Most users will want to follow this pattern - so it's the default that we set.

[github-actions[bot]]

Hello! A team member has marked the above comment as the likely answer to this discussion thread.

• If you agree, please upvote that comment, or click on Mark as answer. I will automatically mark the comment as the answer next time I check.

• If this answer does not help you, please downvote the answer instead and let us know why it was not helpful. I will add a label to this discussion to gain attention from the team.

[erikerikson]

Thank you very much for the response and its treatment of the question.

I understand the importance of ease in the getting started use case and this does provide that. We surely agree that CloudFormation will be used to do many things that one does yet not know at the start. This is exactly why it is confusing to set up a role that must be thereafter sufficient or modifiable (the default of AdministratorAccess as implied by following the getting started documentation is not so) and part of why I and others have had concerns about the escalation risks. It seems very much like defaulting into providing all users sudo rights. The learning curve to avoid that outcome seems high for newer AWS and/or CDK users and without a guide. I and surely others with concerns would benefit from a guide to avoiding these outcomes. Such a guide could be used to help users understand the risks of the easy path to getting started and perhaps a more productionized path to follow for serious use cases.

[peterwoodworth]

Yes I think our bootstrapping documentation in general could use a good overhaul, including making this explicitly clear. I also think adding an in-depth section for bootstrapping in the CDK Workshop would also be cool

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.