aws / aws/aws-cdk

dynamodb: KMSMasterKeyId gets deployed with id rather than arn leading to drift

Open
#35,136 5 comments 0 reactions 0 assignees View on GitHub
@aws-cdk/aws-dynamodb bug effort/medium p1
Dominant language
TypeScript
Stars
12.9k
Forks
4.6k
Avg merge
2d 3h
Merged PRs (30d)
83

Description

### Describe the bug

I have created a table using a customer managed KMS key using theTableV2 construct. Everything deploys fine, and the table is encrypted using the KMS key, but when I run a stack drift detection on the table, it shows a difference

This may be a problem with cloudformation, or cloudformation drift detection, rather than cdk

### Regression Issue

- [ ] Select this option if this issue appears to be a regression.

### Last Known Working CDK Library Version

_No response_

### Expected Behavior

cloudformation drift detection should not show stack drift

### Current Behavior

cloudformation drift detection shows stack drift. The difference appears because the actual version is using the KMS key id rather than the KMS key arn

The difference shows up as this
expected
```
"Replicas": [
{
"SSESpecification": {
"KMSMasterKeyId": "arn:aws:kms:eu-west-2:xxx:key/8e2f7638-ac0e-4373-b2da-f1065838ce7b"
},
```

actual:
```
"Replicas": [
{
"SSESpecification": {
"KMSMasterKeyId": "8e2f7638-ac0e-4373-b2da-f1065838ce7b"
},
...

```

### Reproduction Steps

I am creating a dynamodb table with a CMK with the following code
```
const tokensMappingKmsKey = new Key(this, "TokensMappingKMSKey", {
removalPolicy: RemovalPolicy.DESTROY,
pendingWindow: Duration.days(7),
enableKeyRotation: true
})

const tokenMappingTable = new TableV2(this, "TokenMappingTable", {
partitionKey: {
name: "username",
type: AttributeType.STRING
},
removalPolicy: RemovalPolicy.DESTROY,
encryption: TableEncryptionV2.customerManagedKey(tokensMappingKmsKey),
billing: Billing.onDemand(),
timeToLiveAttribute: "ExpiryTime"
})

```
When I run cdk synth for this the KMS key is added to replicas array, but not the SSE specification for the table
```
...
"Replicas": [
{
"Region": "eu-west-2",
"SSESpecification": {
"KMSMasterKeyId": {
"Fn::GetAtt": [
"TokensMappingKMSKeyB843471F",
"Arn"
]
}
}
}
],
"SSESpecification": {
"SSEEnabled": true,
"SSEType": "KMS"
},
...
```
When this gets deployed and I run drift detection on the stack, it shows as stack drift.
The difference shows up as this
expected
```
"Replicas": [
{
"SSESpecification": {
"KMSMasterKeyId": "arn:aws:kms:eu-west-2:xxx:key/8e2f7638-ac0e-4373-b2da-f1065838ce7b"
},
```

actual:
```
"Replicas": [
{
"SSESpecification": {
"KMSMasterKeyId": "8e2f7638-ac0e-4373-b2da-f1065838ce7b"
},
...

```

According to https://aws.amazon.com/blogs/database/bring-your-own-encryption-keys-to-amazon-dynamodb/, the KMS key should be added to SSESpecification of the table, not the replica, but in https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-dynamodb-globaltable.html it does not include the KMS key in SSESpecification

### Possible Solution

_No response_

### Additional Information/Context

_No response_

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

aws-cdk-lib@2.207.0

### AWS CDK CLI version

2.1022.0 (build b0e6bc0)

### Node.js Version

v22.12.0

### OS

linux

### Language

TypeScript

### Language Version

typescript@5.8.3

### Other information

_No response_

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the issue with the provided TypeScript TableV2 example, then inspect the synthesized GlobalTable Replicas and SSESpecification sections. Compare the deployed resource and drift output to determine whether the discrepancy is introduced by CDK or CloudFormation; done means the ownership and expected behavior are established and the drift is addressed or clearly documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, typescript
Domain
cloud, databases, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.