-
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
(secretsmanager): Partial ARN used in policies and secretFullArn
evaluates to the partial ARN when Secret used across environments
#22468
Comments
secretFullArn
evaluates to the partial ARN when Secret passed across environments
secretFullArn
evaluates to the partial ARN when Secret passed across environmentssecretFullArn
evaluates to the partial ARN when Secret used across environments
We also lost time to this bug, would love to see a fix by AWS. |
@madeline-k can you please take a look? |
I'm not sure where exactly we handle cross-env references, so I'm not too sure where to look for this. However, can you work around this by either passing in the |
One stack has only secrets that are later used in other stacks with ECS services. Originally the reference was handed down as CFN export/import and included the |
… accessed from a cross-env stack (#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 #22468. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
… 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*
Describe the bug
When a
Secret
is created and then passed to a cross-env stack (provided the secret has a specified physical name), its internalarnForPolicies
is its partial ARN without the 6-character suffix. This is wrong, as the generated policies from e.g.grantRead
cannot use the partial ARN as is - they have to append-??????
to it.Expected Behavior
When doing
Secret.grantRead
in a cross-environment stack, the resulting CF template contains the partial ARN of the secret followed by-??????
.Current Behavior
The partial ARN is used as is.
Reproduction Steps
Here's a simple Python app:
Relevant excerpts of the synthed template of the consumer:
The value of
secretFullArn
evaluates to the partial ARN, which is probably related.Possible Solution
No response
Additional Information/Context
In addition, the secret's
secretFullArn
prop evaluates to the partial ARN at synth time (in the consumer stack, that is).CDK CLI Version
2.45.0
Framework Version
No response
Node.js Version
18.9.0
OS
Linux
Language
Python
Language Version
No response
Other information
No response
The text was updated successfully, but these errors were encountered: