dynamodb: KMSMasterKeyId gets deployed with id rather than arn leading to drift
- 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
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