aws / aws/aws-cdk

(aws-s3): expose a bucket's effective encryption mode on the L2 construct

Open
#38,289 2 comments 0 reactions 0 assignees View on GitHub
@aws-cdk/aws-s3 effort/small feature-request p2
Dominant language
TypeScript
Stars
12.9k
Forks
4.6k
Avg merge
2d 3h
Merged PRs (30d)
83

Description

## Describe the feature

Expose the effective server-side encryption mode of an S3 bucket through the L2 API.

`IBucket` currently exposes `encryptionKey?: kms.IKey`, but it does not expose whether the bucket uses SSE-S3, SSE-KMS, or DSSE-KMS. The absence of `encryptionKey` is ambiguous: it can describe SSE-S3, an AWS-managed KMS key, an imported bucket whose encryption is unknown, or another configuration that does not have a grantable customer-managed `IKey`.

This forces constructs that need to vary behavior by encryption mode to inspect `CfnBucket.bucketEncryption` through `node.defaultChild`, retain the original `BucketProps` separately, require callers to repeat the mode in another property, or perform a runtime `GetBucketEncryption` request.

## Use Case

An S3 deployment construct needs to choose a content-identity strategy from the destination bucket's effective encryption:

- SSE-S3 permits a single-part object ETag to be treated as plaintext MD5 evidence.
- SSE-KMS and DSSE-KMS do not permit that assumption and require a different checksum strategy.

The construct receives a CDK-created L2 `Bucket`. Today it has to reach through the L2:

```ts
const resource = bucket.node.defaultChild;
if (!s3.CfnBucket.isCfnBucket(resource)) {
throw new Error("The bucket encryption configuration cannot be inspected");
}

const encryption = Stack.of(this).resolve(resource.bucketEncryption);
```

This couples the construct to the L2's implementation shape and requires it to parse the CloudFormation representation itself. `bucket.encryptionKey` cannot answer the question because AWS-managed KMS and DSSE configurations do not provide a customer-managed `IKey`.

The distinction is useful beyond deployment constructs. Integrations may need it to select checksum behavior, validate service compatibility, or configure encryption-specific IAM without guessing from the presence of a KMS key.

## Proposed Solution

Add an optional, read-only encryption-mode property to the L2 contract, for example:

```ts
export interface IBucket extends IResource, IBucketRef {
/**
* The effective default server-side encryption mode for this bucket.
*
* @default - unknown for imported or unresolved buckets
*/
readonly encryption?: BucketEncryption;
}
```

For CDK-created `Bucket` instances, derive the value from the underlying `CfnBucket` so L1 overrides and Aspects remain the source of truth. The existing internal `BucketReflection` mechanism already reads L1-backed properties and could be extended with an encryption-mode getter.

Suggested behavior:

| Synthesized/default state | L2 value |
| --- | --- |
| No explicit `BucketEncryption` configuration | `BucketEncryption.S3_MANAGED`, reflecting S3's effective default encryption |
| `AES256` | `BucketEncryption.S3_MANAGED` |
| `aws:kms` with the AWS-managed S3 key | `BucketEncryption.KMS_MANAGED` |
| `aws:kms` with a customer-managed key | `BucketEncryption.KMS` |
| `aws:kms:dsse` with the AWS-managed S3 key | `BucketEncryption.DSSE_MANAGED` |
| `aws:kms:dsse` with a customer-managed key | `BucketEncryption.DSSE` |
| Imported bucket without supplied encryption information | `undefined` |
| Tokenized or otherwise unresolved configuration | `undefined` |

If adding the property to `IBucket` is too broad, exposing the same information through a supported public reflection API would still avoid consumer-owned L1 parsing. The important part is preserving an explicit distinction between effective SSE-S3 and an unknown imported configuration.

## Other Information

The current L2 exposes `encryptionKey`, while the newer `BucketReflection` implementation can locate the underlying `CfnBucket` and its related KMS key. It does not currently expose the bucket's encryption mode.

This should be additive if the new property is optional. It should not require changing the existing `encryptionKey` behavior.

## Acknowledgements

- [x] I may be able to implement this feature request
- [ ] This feature might incur a breaking change

## AWS CDK Library version (aws-cdk-lib)

2.260.0

## AWS CDK CLI version

2.1127.0 (build 425ccb0)

## Environment details (OS name and version, etc.)

Ubuntu 24.04

Contributor guide

Open the contributing guide

Research direction

Start with the public IBucket contract and the existing BucketReflection implementation that reads the underlying CfnBucket. Trace bucketEncryption, including default, SSE-S3, KMS, DSSE-KMS, imported, and unresolved cases. Done means exposing an optional effective encryption mode without changing encryptionKey behavior, with coverage for the listed mappings.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, typescript
Domain
cloud, infrastructure
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.