Skip to content
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

Improve secretsmanager to generate unique secret names based on the secret data #10857

Open
MartinWeindel opened this issue Nov 14, 2024 · 0 comments
Labels
area/robustness Robustness, reliability, resilience related kind/enhancement Enhancement, improvement, extension

Comments

@MartinWeindel
Copy link
Member

MartinWeindel commented Nov 14, 2024

How to categorize this issue?

/area robustness
/kind enhancement

What would you like to be added:
The secrets manager (pkg/utils/secrets/manager) calculates the name for generated secrets using a hash code from the passed config ( secretsutils.ConfigInterface). The generated secret data itself is not reflected in the calculated name. It is good practice to have unique names based on the data for immutable secrets.
For example, if for any reason the secret is deleted and regenerated, it has the same name, but can contain different data if the generation uses randomisation.
A possible solution could be to use the calculated name as value for an additional label and use it to find an already existing secret for a given config. The secret name itself would then be calculated using a hash of the secret data.

Why is this needed:
As the secret is marked immutable, it is not watched by kubelets. A kubelet may still cache the old secret data. Even new pods may still see the old secret data if the secret is mounted as volume. This can lead to strange effects very hard to understand.
Losing a secret should not happen on normal operation, but it would improve the robustness if a regenerated secret has a different name after such an unexpected incident.

@gardener-prow gardener-prow bot added area/robustness Robustness, reliability, resilience related kind/enhancement Enhancement, improvement, extension labels Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/robustness Robustness, reliability, resilience related kind/enhancement Enhancement, improvement, extension
Projects
None yet
Development

No branches or pull requests

1 participant