You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(cli): S3 asset uploads are rejected by commonly referenced encryption SCP (introduces bootstrap stack v9) (#17668)
Many organizations around the world have started to use a specific Service Control Policy (SCP) from this blog post: https://aws.amazon.com/blogs/security/how-to-prevent-uploads-of-unencrypted-objects-to-amazon-s3/ in order to make sure all S3 bucket uploads are encrypted.
CDK configures the `DefaultEncryptionConfiguration` on the bucket so that objects are always encrypted by default, but this specific SCP can only check that individual upload actions include the "enable encryption" option. That means that even though the end result would still be satisfied (objects are encrypted in S3), the SCP would nevertheless reject the CDK upload. We would rather people use AWS Config to make sure all buckets have `DefaultEncryptionConfiguration` set, so that this SCP is not necessary... but there is no arguing with deployed reality.
Change the CDK upload code path to first read out the default encryption configuration from the bucket, only to then mirror those exact same settings in the `PutObject` call so that the SCP can see that they are present.
This requires adding a new permission to the `cdk-assets` role, namely `s3:GetEncryptionConfiguration`, so requires a new bootstrap stack version: version 9.
If you want this new behavior because your organization applies this specific SCP, you must upgrade to bootstrap stack version 9. If you do not care about this new behavior you don't have to do anything: if the call to `getEncryptionConfiguration` fails, the CDK will fall back to the old behavior (not specifying any header).
Fixes#11265.
----
*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
this.host.emitMessage(EventType.DEBUG,`No bucket named '${destination.bucketName}'. Is account ${awaitaccount()} bootstrapped?`);
63
+
break;
64
+
caseBucketEncryption.ACCES_DENIED:
65
+
this.host.emitMessage(EventType.DEBUG,`ACCES_DENIED for getting encryption of bucket '${destination.bucketName}'. Either wrong account ${awaitaccount()} or s3:GetEncryptionConfiguration not set for cdk role. Try "cdk bootstrap" again.`);
0 commit comments