-
Notifications
You must be signed in to change notification settings - Fork 4.3k
fix(dynamodb): use keyId instead of keyArn for TableV2 replica encryption #35144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(This review is outdated)
Exemption Request Why no new integration test is needed:
|
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
This pull request has been removed from the queue for the following reason: The pull request can't be updated. You should update or rebase your pull request manually. If you do, this pull request will automatically be requeued once the queue conditions match again. |
@Mergifyio rebase |
…cryption Fixes CloudFormation drift detection for DynamoDB TableV2 with customer-managed KMS encryption. Previously, CDK generated templates using KMS key ARN, but DynamoDB internally stores only the key ID, causing false positive drift detection. Changes: - encryption.ts: Use tableKey.keyId instead of tableKey.keyArn in _renderReplicaSseSpecification - Update test expectation to match corrected CloudFormation output (Ref vs Fn::GetAtt) Fixes aws#35136
✅ Branch has been successfully rebased |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Comments on closed issues and PRs are hard for our team to see. |
Issue # (if applicable)
Closes #35136.
Reason for this change
DynamoDB TableV2 construct with customer-managed KMS encryption causes CloudFormation drift detection to report false positives. This occurs because CDK generates CloudFormation templates using KMS key ARNs (
Fn::GetAtt
withArn
), but DynamoDB internally stores only the key ID, leading to a mismatch during drift detection.Description of changes
Root Cause: The
_renderReplicaSseSpecification
method inencryption.ts
was usingtableKey.keyArn
which generatesFn::GetAtt
withArn
, but the CloudFormation L1 propertyKMSMasterKeyId
expects a key ID, not an ARN. While DynamoDB accepts ARNs at deployment time, it internally stores and returns only the key ID, causing drift detection mismatches.Solution: Changed
tableKey.keyArn
totableKey.keyId
on line 73 ofencryption.ts
. This generates aRef
to the KMS key resource, which produces the key ID format that aligns with:KMSMasterKeyId
property specificationFiles Modified:
packages/aws-cdk-lib/aws-dynamodb/lib/encryption.ts
: Updated KMS key reference from ARN to IDpackages/aws-cdk-lib/aws-dynamodb/test/table-v2.test.ts
: Updated test expectation to match corrected CloudFormation outputImpact: This fix eliminates false positive drift detection for DynamoDB TableV2 constructs using customer-managed KMS encryption while maintaining full backward compatibility.
Describe any new or updated permissions being added
No new or updated IAM permissions are required. This change only affects the CloudFormation template generation format to properly align with the
KMSMasterKeyId
property specification.Description of how you validated changes
Unit Tests:
table-v2.test.ts
to verify correct CloudFormation output format (Ref vs Fn::GetAtt)Integration Tests:
Manual Validation:
Ref
instead ofFn::GetAtt
for KMS key referencesKMSMasterKeyId
property expectationRegression Testing:
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license