Custom CDK bootstrap roles

Why?

CDK requires that you run the bootstrap command before you can deploy stacks using CDK in that account. Part of this bootstrapping is to create IAM roles that will be assumed by CDK. There also a particular role, cfn-exec-role, that will be assumed by CloudFormation to actually create/update/delete the stack’s resources. This role has AdministratorAccess. You can imagine how this makes security folk squirm.

How?

There are two sides to this. The first is the cfn-exec role itself. The permissions should be scoped to what services your stacks are using. If you’re building web backends or services then you don’t probably need permission for Ground Station.

AWS Ground Station is a fully managed service that lets you control satellite communications, process data, and scale your operations without having to worry about building or managing your own ground station infrastructure.

Or maybe a more realistic scenario is that the IAM permissions themselves are limited to certain actions rather than just full managment iam:*.

The second side is making sure that this scoped role is used when running cdk deploy. This is done by updating the CDK context.

{
  "context": {
      "@aws-cdk/core:bootstrapQualifier": "my-qualifier"
  }
},

You use what’s called a qualifier. The pattern CDK uses for the roles is cdk-{qualifier}-yadayada. The default bootstrap will use hnb659fds as the qualifier. So you add custom bootstrap roles with a different qualifier and you point CDK at that using the context in cdk.json.

How to do it well?

Now, this is the way I, and others at work, have decided to do it. This doesn’t mean it’s the only way or the best way. We have decided to create different custom bootstrap roles based on teams that are using CDK. Meaning each team has their own qualifier to use and it is scoped to have permissions they need. We have a small number of teams currently but I think this could work for a larger number of teams too.

The way this is managed is through IaC, CloudFormation in this case, but it could done via CDK. The cfn-exec role is really where the permissions need to be scoped. So the bootstrap is common across the various team qualifiers except for the permissions assigned to the cfn-exec role.

Now admittedly this can create some friction when retrofitting this. It would be easier to do this from the beginning and add services as needed. It requires a bit of trial and error. Depending on the granularity of permissions you want it will be more or less painful.

One thing that can be helpful is to use a prod guard. Rather than making the change in cdk.json. You make it in the entry point to your app. You can set the @aws-cdk/core:bootstrapQualifier to be conditional. If the environment is not production then change it to the new qualifier. This way you can test out how the custom bootstrap role is working but without the fear that a production deployment is going to fail because of a missing IAM permission.