Open qike-ms opened 5 years ago
We have been talking about this and i have been taking an opposing position. Updating the key requires a rolling update to the application pods. That protects against:
If the volume gets updated on the fly, we could use https://github.com/stakater/Reloader to auto re-deploy. There is value in allowing for rapid/automated secret rotation.
We have been talking about this and i have been taking an opposing position. Updating the key requires a rolling update to the application pods. That protects against:
- A situation where the entire application are unavailable during config reload across all replicas.
- Protects against fat fingering a config file and mistakenly pushing it to clusters.
@khenidak that assumes that chaging the keys is always a human/ci/cd interaction, but in case there are some scenarios such as automation key rotation configurations that would make it more complex to do a rolling update just because the dependent system did its normal key change.
Hi guys any updates on this ?
Any update on this backlog item, what's the priority of this in backlog any timeline/update ?
Hi guys any updates on this ?
hi folks....any progress / alternative please?
@gkriti1988 https://github.com/Azure/secrets-store-csi-driver-provider-azure is the next generation of this flexvol solution/repo. Please start using the secrets store csi driver and Azure Key Vault provider as this solution will slowly be deprecated.
We are working on adding automatic reload for the mounted contents feature in the secrets-store-csi-driver. The feature is being tracked here - https://github.com/kubernetes-sigs/secrets-store-csi-driver/issues/125
Right now, the value of the key is only set at the time when the keyvault is mounted which is the time when the pod starts. To get subsequent updates, pod needs to be restarted. Can we add a sidecar to watch the value and update the value in the mounted volume?