Aws-cdk: [cdk-pipelines] shellable and s3-deployments in a legacy stack don't work with new bootstrap resources

[rix0rrr]

New bootstrap bucket is encrypted, but legacy apps have no knowledge of the fact that buckets even COULD be encrypted and won't ever add kms:Decrypt permission to roles using assets.

Not a problem for Lambdas, but is a problem for in-line roles trying to read file assets.

---

This is :bug: Bug Report

[rix0rrr]

Here's what needs to happen:

• CLI needs to lookup whether the current bootstrap stack has a KMS key or no (old bootstrap stack doesn't but new bootstrap stack does)
• Needs to pass the ARN into the app via context
• legacy synthesizer needs to report the ARN if present

[rix0rrr]

This actually can't be properly solved.

The DefaultStackSynthesizer is designed to only work with the new bootstrap resources, so it can (semi-safely) always assume that it the bucket is encrypted(¹) and that the key ARN is available as an Export, so it generates this:

    {
        Action: ['kms:Decrypt', 'kms:DescribeKey'],
        Effect: 'Allow',
        Resource: { 'Fn::ImportValue': 'CdkBootstrap-hnb659fds-FileAssetKeyArn' },
   }

The LegacyStackSynthesizer should be able to work with either the old or the new bootstrap resources. It therefore needs to know whether the bootstrap bucket is encrypted or not, and the key ARN, in order to generate the above statement.

There is no automatic way of loading this information. We need it at synth time. The CLI can't look it up, because it needs to synth first before it even knows what stacks exist and what the accounts/regions are where they would be deployed. So at the time it would need to perform the lookup, it doesn't have enough information to know what to even look up.

The only possible way to do it with double-least-privilege policies is by having the user manually configure the key ARN for every stack.

The only solution that is zero-conf would be to replace the role policy with:

    {
        Action: ['kms:Decrypt', 'kms:DescribeKey'],
        Effect: 'Allow',
        Resource: ['*'],
   }

This is not actually insecure as KMS keys need to validate on both policies, both the key policy as well as the role policy. So by setting the role policy to kms:Decrypt on *, key access is still controlled by the key policy.

We need to validate that AppSec is okay with this though.

(¹) on the other hand, if users customize their bootstrap stack and *don't want the bucket encrypted, they will be forced to leave the Export in place and put a dummy ARN in there (and hope the ARN isn't validated to point to an existing key), or no deployment will be able to happen*