(cli): reduce deploy role scope

Currently the deploy role has a lot of access to *:

https://github.com/aws/aws-cdk/blob/b96efd8aaa143845b9fe315a9ee1e8398c4d83c2/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml#L314-L336

I wonder if we can scope this down a bit by qualifier, so one bootstrap instance can’t access things from another? Maybe with tags or enforcing a naming scheme? E.g. all stacks must start with cdk-${qualifier}-

Use Case

We’re investigating bootstrapping for each service with different qualifiers to try and reduce the blast radius if access to the deployment role (and others) from one bootstrap instance is compromised. The other roles/policies look like they’re scoped pretty well. The FilePublishingRoleDefaultPolicy for example can only be used with the StagingBucket.Arn for that bootstrap instance.

I think we’ll need to create a custom deploy role which can only invoke specific CloudFormation stacks with a restricted execution policy (unless this could be an official feature of the bootstrap stack in the future), but was looking to use this as a template, and if this level of access is really needed, I think the isolation we want really isn’t going to be possible.

Thanks.

Proposed Solution

I’m not sure if we can actually scope the permissions down from *. The comment

# Permissions needed in CodePipeline.
# S3 and KMS are needed on '*',
# as we don't know the IDs of the CodePipeline's bucket and key in advance

makes it sound like we can’t, but I’m really hoping that’s not the case.

• 👋 I may be able to implement this feature request (depending what the solution ends up being)
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[Wenzil]

To pile on https://github.com/aws/aws-cdk/issues/12985#issuecomment-802793593, here are additional Pros for the proposed change:

• Reap benefits from current and future features of CDK tooling
  • For example, the CDK CLI heuristically detects security posture changes when cdk diff or cdk deploy is executed. Logging the security report would be a welcome improvement only possible with CDK tooling. Related to https://github.com/aws/aws-cdk-rfcs/issues/282
• Less reliance on CodePipeline self-mutation
  • Adding a new stack to your application deployment stage? Currently, CodePipeline needs to self-mutate to add the corresponding CloudFormation action. With the change, the pipeline definition does not need to mutate. Self-mutation becomes required only when the pipeline itself needs to be updated
    • E.g. when adding pre-build steps to the synth stage
    • E.g. when upgrading the CDK version used for (future) self-mutations
    • E.g. when changing the target environment of deployments (to update the pipeline role permissions)
  • Disabling self-mutation (already supported) becomes actually viable - this aligns with the common separation of responsibilities where an ops team manages CI/CD pipelines and developers only use existing CI/CD pipelines for their deployments
  • Self-mutation is so hard to reason about in many cases. The less reliance on it, the better
• No reliance on the CodePipeline cross-region support stack for cross-region deployments
  • Deploying to a different region? Currently this requires a support stack and setting up CodePipeline for cross-region replication of artifacts. This is taken care of by CDK but adds unnecessary complexity. With the change, bootstrapping the target environment region is sufficient.

[tjenkinson]

I believe what’s happening is CodePipeline is generating a presigned URL for the template and passing that URL to CloudFormation.

Yep this seems to be the case. Opened a PR to get docs updated and hopefully confirmation of that.

action use a role in A, and then pass the execution role from account B to CloudFormation

This doesn’t work either. Get

Cross-account pass role is not allowed.

so created another PR to document that and get confirmaton.

Spending so much time trying things that could have been avoided if the docs were clearer 😐

---

Back to one of my original questions:

I wonder if we could switch to a solution where we use the CodePipeline CloudFormation action for same account deploys, but for cross account switch to CodeBuild and either using the CDK to deploy or a CloudFormation API call?

I’m wondering what the gain really is of using the built-in actions (even for same account deploys) over having a single CodeBuild step with cdk deploy, that does everything? That action would just need to run as a role that can assume the deploy and file publish roles that are in the manifest (which would be updated in the UpdatePipeline stage if necessary).

It would make the code simpler and remove the need for these * permission on the deploy role, given the template would be uploaded to the artifact bucket of account B (key point) if it needed to be.

Pros:

• deploy role no longer has access to deploy keys and all s3 buckets in the account it’s part of and other accounts that have the resource policies allowing it, because account B would no longer need to be able to access the pipeline artifact bucket in account A.
  • we have discussed an approach to reduce this to only allow access to accounts that are not the account the role is contained in, and this should work, but is still a bit leaky and adds complexity to the bootstrap template that is not needed IMO, and also not needed for anyone not using the pipelines module
• It’s a single CodeBuild job vs multiple asset upload stages and CloudFormation stages, so will probably be quicker in general, and given it’s a standard cdk deploy people will understand the log output and any errors should be clear.
• Resulting pipeline stack should be smaller
• If a cross account deploy fails due to a CloudFormation error, the CloudFormation errors should be visible in the cdk deploy output.
  • The CodeBuild CloudFormation action links to the stack to see the events, which is sometimes hard/impossible to get to if it’s a different account.
• Code should be simpler because we don’t need to split the cdk artifact into assets and templates anymore

Cons:

• Don’t get the nice CodePipeline CloudFormation UI and it’s not split up visually into the seperate parts
  • but does it really need to be? One of the gains is it makes it easier to see which part fails (but on the other hand it’s actually harder to get the reason why it failed sometimes), but given all this is managed by the CDK, it shouldn’t fail anyway. If it did, the cdk deploy output should already be clear.
• Cost. Running CodeBuild may be more expensive than CloudFormation actions.

@rix0rrr thoughts? Have I missed some cons? Should this be an RFC?