-
Notifications
You must be signed in to change notification settings - Fork 53
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
Use MutatingWebHook for generating secrets #28
Comments
There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the |
Since this is already getting stale... Thanks for the suggestion, and 👍 from me on the general idea -- this would completely eliminate the (however short) period in which a required secret value would be missing and save us all the reconciliation loops. However, since this is quite a major change, I cannot make any promises as to if and when we'd be getting to building this. As usual, any PRs in this matter are most welcome. |
Is your feature request related to a problem? Please describe.
It's a feature request, to prevent potential race condition problems.
The current implementation seems to be watching secrets in certain or all namespaces.
The problem is that a secret that is created might be attached to pods using environment variables (valueFrom: ...). But, at the time of being attached, the generator might not yet generate the required secret keys.
So there is a situation where a pod could be attached to a secret before the values are actually generated.
Describe the solution you'd like
By using a MutatingWebHook, the secret keys would be generated before the secret is available to pods.
The MutatingWebHook lifecycle will be triggered before the secret could be admitted, and it would prevent this race condition altogether.
Describe alternatives you've considered
Restart the pod if the key is not present on the secret
The text was updated successfully, but these errors were encountered: