Improve secretsmanager to generate unique secret names based on the secret data #10857
Labels
area/robustness
Robustness, reliability, resilience related
kind/enhancement
Enhancement, improvement, extension
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.
The text was updated successfully, but these errors were encountered: