-
-
Notifications
You must be signed in to change notification settings - Fork 1k
feat: Allow removing KMS and SSM permissions from EKS IRSA external secrets policy #550
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
feat: Allow removing KMS and SSM permissions from EKS IRSA external secrets policy #550
Conversation
This PR has been automatically marked as stale because it has been open 30 days |
be40269
to
549ea31
Compare
Proposed fix for #557 |
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.
Just ran into this issue myself earlier today, this fix would be most welcome to see implemented! Thanks for your efforts!
I'd like the option to remove access to KMS and SSM permissions on my IRSA roles while still providing the ability to use this module with the default encryption key provided by AWS. When I attempt to provide an empty list, the IAM policy is invalid because a resource definition is required.
549ea31
to
82eab62
Compare
## [5.55.0](v5.54.1...v5.55.0) (2025-04-14) ### Features * Allow removing KMS and SSM permissions from EKS IRSA external secrets policy ([#550](#550)) ([bfaa70d](bfaa70d))
This PR is included in version 5.55.0 🎉 |
Description
I'd like the option to remove access to KMS and SSM permissions on my IRSA roles while still providing the ability to use this module with the default encryption key provided by AWS. When I attempt to provide an empty list, the IAM policy is invalid because a resource definition is required.
Motivation and Context
Most of the secrets in my environment have been created with the default encryption key, so they don't need any special access to KMS or SSM. When attempting to remove this permission I ran into an error applying the configuration because the policy document was malformed.
Resolves #557
Breaking Changes
No, this is not a breaking change as the existing default remains intact.
How Has This Been Tested?
examples/*
to demonstrate and validate my change(s)examples/*
projectspre-commit run -a
on my pull request