-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
fix(secretsmanager): arnForPolicies
evaluates to the partial ARN if accessed from a cross-env stack
#26308
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.
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.
Not sure how to go about an integration test - I've written one but then realized that the AWS account number has to be provided (and included in the snapshots) since the stacks have to be environment-specific - what is the process in this case? |
Hm, the integ tests failed because
changed to
Any idea why this could be? |
(Sorry I accidentally closed this) |
Which test is this?
I suspect the policy deduplication mechanism (search for |
It is aws-rds/test/integ.serverless-cluster-secret-rotation-custom-names and aws-rds/test/integ.serverless-cluster-secret-rotation This would make it a breaing change, though. Regarding an integration test for the fix itself - I'm not really comfortable with making it exempt, but not sure how a env-specific integ test can possibly be implemented. |
Back to square one then.
Have you figured out why this happens? |
I believe it's because the default implementation of |
We could change |
Hm, so I guess that makes |
No, it works fine with cross-stack references if in the same environment (using Cfn imports under the hood). The relevant logic for cross-stack references is implemented elsewhere. |
Yeah, but could we use the same/similar logic for cross-env? |
Well, Cfn imports don't work cross-env. The cross-env logic is just "resolve the references at synth time". What do you think we should be focusing on (I'm getting a bit lost in the discussion)? |
To make sure we're on the same page - detecting that it's a cross-env reference is not the issue - that's easy. Returning a correct We can have But the issue with merging in IAM policies would still be there in both of these cases, as far as I understand. |
I'm with you now. Having |
Nervermind. Figured it out. |
✅ 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). |
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). |
… accessed from a cross-env stack (aws#26308) Currently, `Secret.secretFullArn` returns the partial ARN if the secret is referenced between cross-env stacks. An obvious practical implication is that `grant*` methods will produce an incorrect ARN for the IAM policies, since a full ARN is required for cross-environment access. This PR partially fixes the issue - I reimplemented `arnForPolicies` to be lazily evaluated. It checks if the value is being accessed across environments and adds `-??????` to the ARN if it is. Now, this does not solve the underlying issue of `secretFullArn` returning the partial ARN. While it should return undefined, we have to check how the prop is accessed (same environment or cross-env) before we know whether to return the ARN or `undefined`. If we use a `Lazy` here, it still cannot return `undefined` (only `any` as the closest thing). So I don't think the underlying cause could be solved currently, that's why I opted for this partial fix that would address the most practical consequence of the bug. This is a partial fix for aws#22468. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@gshpychka @mrgrain This unfortunately break my app. I believe this is because the condition So either the if block should only be entered if fullArn is undefined and cross-region or arnForPolicies should be overriden in class returned fromSecretAttributes. This is a nice fix for secrets created(not imported) cross-region which would reduce some complexity in my apps since it has this case too. |
@rv2673 Thanks for letting us know! Would you mind creating a new issue for this and include a code sample for the reproduction. Thank you. |
Currently,
Secret.secretFullArn
returns the partial ARN if the secret is referenced between cross-env stacks.An obvious practical implication is that
grant*
methods will produce an incorrect ARN for the IAM policies, since a full ARN is required for cross-environment access.This PR partially fixes the issue - I reimplemented
arnForPolicies
to be lazily evaluated. It checks if the value is being accessed across environments and adds-??????
to the ARN if it is.Now, this does not solve the underlying issue of
secretFullArn
returning the partial ARN. While it should return undefined, we have to check how the prop is accessed (same environment or cross-env) before we know whether to return the ARN orundefined
. If we use aLazy
here, it still cannot returnundefined
(onlyany
as the closest thing).So I don't think the underlying cause could be solved currently, that's why I opted for this partial fix that would address the most practical consequence of the bug.
This is a partial fix for #22468.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license