feat(s3): add blockedEncryptionTypes field to s3.Bucket

[ysthakur]

Issue

Closes #36988.

Reason for this change

S3 recently added a new BlockedEncryptionTypes field to server-side encryption rules (docs). This field allows users to explicitly block or unblock SSE-C encryption on their bucket.

Users should be able to set this field through CDK. This will become especially important when SSE-C starts being blocked by default in April (blog post).

Description of changes

Added a blockedEncryptionTypes field to the L2 s3.Bucket construct.

• If blockedEncryptionTypes is not set, behavior is same as before. No default blockedEncryptionTypes value will be chosen (this is important, we want to let S3 choose what default to apply).
• If blockedEncryptionTypes is set and encryptionType is BucketEncryption.UNENCRYPTED, a server-side encryption configuration will be added with just blockedEncryptionTypes
  • This happens even if bucketKeyEnabled is explicitly set. Please confirm that this is behavior you want. I went with it because bucketKeyEnabled is already ignored when encryptionType is BucketEncryption.UNENCRYPTED.

Describe any new or updated permissions being added

N/A

Description of how you validated changes

Ran unit tests, added integ tests.

• Verified that the MySsecBlockedBucket bucket has SSE-C blocked (and no default server-side encryption type explicitly set)
• Verified that the MyKmsBucket bucket has no encryption types blocked

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[ysthakur]

Yes, this isn't a particularly helpful comment, but I wrote this because the default is going to change soon. Right now, no encryption types are blocked by default, but in April, SSE-C will start being blocked by default. When that happens, we can update this to say @default - SSE-C is blocked by default.

An alternative is to say @default - no encryption types are blocked, but SSE-C will start being blocked in April 2026, but putting times in doc comments feels wrong.

[ysthakur]

Any idea why the PR Linter workflow is failing with "Bad credentials"?

[github-actions]

⚠️ Experimental Feature: This security report is currently in experimental phase. Results may include false positives and the rules are being actively refined.
Please try merge from main to avoid findings unrelated to the PR.

---

	Tests	Passed ✅	Skipped	Failed
Security Guardian Results	24 ran	24 passed

Test	Result
No test annotations available

• View Security Guardian Results

[github-actions]

⚠️ Experimental Feature: This security report is currently in experimental phase. Results may include false positives and the rules are being actively refined.
Please try merge from main to avoid findings unrelated to the PR.

---

	Tests	Passed ✅	Skipped	Failed
Security Guardian Results with resolved templates	24 ran	24 passed

Test	Result
No test annotations available

• View Security Guardian Results with resolved templates

[aws-cdk-automation]

(This review is outdated)

[trevormgoodell]

Should we have a test that if nothing is provided here then we don't expect there to be a BlockedEncryptionTypes in the BucketEncryption?

[ysthakur]

Yeah, makes sense

[ysthakur]

Actually, we already have tests that makes sure that if we don't specify blockedEncryptionTypes, the either BucketEncryption is empty (if bucketEncryption is UNENCRYPTED) or there's no BlockedEncryptionTypes in the CFN template: https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-s3/test/bucket.test.ts#L43-L142

I'm not sure if that's what you meant. The intent of those tests isn't actually checking for blockedEncryptionTypes so I guess it's possible they accidentally get removed in the future, but I think it's unlikely

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.