fix(secretsmanager): secret resource policy already exists in stack (under feature flag) #24365
Conversation
There was a problem hiding this comment.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.
mrgrain
added
@aws-cdk/integ-tests
pr-linter/exempt-integ-test
aws-cdk-automation
dismissed
their stale review
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
mrgrain
added
pr/do-not-merge
There was a problem hiding this comment.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.
mrgrain
changed the title
The issue is prevalent with Database clusters, e.g. when a secret with a rotation is used and a grantee is granted access to the db cluster. The root cause of this issue is the Cluster's use of a SecretAttachmentTarget to replace the original secret. This is allowed, since SecretAttachmentTarget do implement the ISecret interface. When policy statements are added, a new resource policy is created using the SecretAttachmentTarget ARN. This only works because in CloudFormation SecretAttachmentTarget returns the ARN of the Secret. However a secret can only have a single resource policy. The above scenario leads to a policy being created for the Secret and one for the SecretAttachmentTarget. Which is then (correctly) rejected by CloudFormation. The fix is to forward any policy changes of the SecretAttachmentTarget to the attached secret.
mrgrain
force-pushed
the
mrgrain/fix/secret-can-only-have-one-policy
branch
from
0b85181
to
5c65f97
Compare
aws-cdk-automation
dismissed
their stale review
✅ Updated pull request passes all PRLinter validations. Dissmissing 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). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
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). |
…under feature flag) (aws#24365) The issue is prevalent with Database clusters, e.g. when a secret with a rotation is used and a grantee is granted access to the db cluster. The root cause of this issue is the Cluster's use of a SecretAttachmentTarget to replace the original secret. This is allowed, since SecretAttachmentTarget do implement the ISecret interface. When policy statements are added, a new resource policy is created using the SecretAttachmentTarget ARN. This only works because in CloudFormation SecretAttachmentTarget returns the ARN of the Secret. However a secret can only have a single resource policy. The above scenario leads to a policy being created for the Secret and one for the SecretAttachmentTarget. Which is then (correctly) rejected by CloudFormation. The fix is to forward any policy changes on the SecretAttachmentTarget to the attached secret. Fixes aws#24383 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
The issue is prevalent with Database clusters, e.g. when a secret with a rotation is used and a grantee is granted access to the db cluster.
The root cause of this issue is the Cluster's use of a SecretAttachmentTarget to replace the original secret. This is allowed, since SecretAttachmentTarget do implement the ISecret interface. When policy statements are added, a new resource policy is created using the SecretAttachmentTarget ARN. This only works because in CloudFormation SecretAttachmentTarget returns the ARN of the Secret. However a secret can only have a single resource policy. The above scenario leads to a policy being created for the Secret and one for the SecretAttachmentTarget. Which is then (correctly) rejected by CloudFormation.
The fix is to forward any policy changes on the SecretAttachmentTarget to the attached secret.
Fixes #24383
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license