Prerequisites
If deploying via helm:
-
installing the secrets-store-csi-driver v1.1.0 or later separately using
--set tokenRequests[0].audience="vault"to facilitate agent caching - vault-helm 0.25.0 or later
If deploying via other methods and or upgrading:
- installing the secrets-store-csi-driver v1.1.0 or later separately using
--set tokenRequests[0].audience="vault"to facilitate agent caching - vault-csi-provider v1.4.0 or later
- vault-agent v1.14.0 or later
- ensure the CSI daemonset is talking to the vault agent via the vaultAddress
-
- name: VAULT_ADDR
value: "unix:///var/run/vault/agent.sock" - and like wise ensure the vault agent is listening on that socket as well which will need to be manually configured as per the template here
Overview
As of the vault-csi-provider v1.4.0 release in response to this issue now has the capacity to allow the vault agent side car to manage the lifetime of a secret, or rather, it's lease renewal so to enable more ephemeral secrets in a CSI driver managed deployment.
Procedures
If implementing for the first time in a kubernetes deployment, it is recommended to install via the helm chart v 0.25.0 or later and the functionality should be automatically available.
If upgrading from an earlier version of the helm chart or manually as per the above requirements. As the vault agent side car needs to "own" the lease, it may be necessary to remove the SPC, delete the pods, expire the existing lease in Vault and redeploy.
To identify if your agent does or doesn't own the lease when handling requests the agent logs will report actions being proxied i.e.
[INFO] agent.apiproxyIf the agent is managing the lease, debug level logs will report cache processing i.e.
[DEBUG] agent.cache.leasecache
Alternative Note
If considering using the kubernetes secrets store csi driver, the vault provider and vault agent to render and renew secrets, an alternative method would be to use the Vault Secrets Operator which is now generally available. Additional documentation can be found here.