-
Notifications
You must be signed in to change notification settings - Fork 4k
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
(iam): policies created with grant interface in different stacks have the same name and overwrite each other #16074
Comments
I'm having the same with grants on kms keys. |
This looks like the same problem as #7483 |
I've reproduced this successfully. |
…h other in multi-stack deployments (#20705) This adds a prop, `defaultPolicyName`, that can be specified for imported roles. If the same role is imported in at least two stacks, and both of them create grant permissions to that role, the permissions granted in whichever stack was deployed last will overwrite the permissions granted by all others. Specifying this option allows users to specify different policy names across different stacks, which will prevent this overwrite issue. Closes #16074. ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
…h other in multi-stack deployments (aws#20705) This adds a prop, `defaultPolicyName`, that can be specified for imported roles. If the same role is imported in at least two stacks, and both of them create grant permissions to that role, the permissions granted in whichever stack was deployed last will overwrite the permissions granted by all others. Specifying this option allows users to specify different policy names across different stacks, which will prevent this overwrite issue. Closes aws#16074. ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
I'm importing a role in two separate stacks to add permissions to resources created in those stacks and they end up overwriting each other
Reproduction Steps
stack 1 has:
stack 2 has:
What did you expect to happen?
I expected two policies to be added to the role allowing put permission to myEventbridge and allowing invoke on myLambda.
What actually happened?
I only get one of these permissions. The policy name generated is the same for both (in my case something like 'myRolePolicy3334F5F9') so one ends up overwriting the other.
I've worked around this by changing the imported role id in each stack to be unique but I find this troubling as it is extremely easy to accidentally overwrite policies set in a different stack. Shouldn't names be unique by stack?
Environment
Other
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: