f a selected secret (i.e. one with label secret-generator.cs.sap.com/enabled: "true") gets deployed before the mutating webhook definition for the kubernetes-secret-generator webhook is deployed/active, then that secret will be silently persisted unchanged (i.e. without replacing the %generate:... token by the desired generated value).
This problem is more or less intrinsic to all webhooks, but here it might remain unnoticed for a long time, and might create a real security issue.
Proposal: this webhook could at least passively watch all selected secrets, and expose any missed ones via a prometheus metric, that could be used for an alert ...
Of course, one could also think about re-processing such a missed secret asynchronously, but that would still not mean that consuming applications reload it and do not continue to use the previous values.
TheBigElmo
commented
5 months ago
f a selected secret (i.e. one with label secret-generator.cs.sap.com/enabled: "true") gets deployed before the mutating webhook definition for the kubernetes-secret-generator webhook is deployed/active, then that secret will be silently persisted unchanged (i.e. without replacing the %generate:... token by the desired generated value).
This problem is more or less intrinsic to all webhooks, but here it might remain unnoticed for a long time, and might create a real security issue.
Proposal: this webhook could at least passively watch all selected secrets, and expose any missed ones via a prometheus metric, that could be used for an alert ...
Of course, one could also think about re-processing such a missed secret asynchronously, but that would still not mean that consuming applications reload it and do not continue to use the previous values.
Moved from https://github.tools.sap/cs-devops/kubernetes-secret-generator/issues/1