I was watching this video https://youtu.be/PNtRk3wRtWM?t=1151, and I must disagree with the presenter. Expiring secrets created with auto_auth token, is not surprising, is alarming! It sounds like secrets are tied to the agent, why would we need Vault for?
I’m hopeful it’s just I that don’t understand this king of tokens. So here’s the question:
Using Vault Agent Auto Auth, do secrets created with the kv engine become inaccessible under these circumstances:
- The solution is re-deployed, causing the agent to restart and retrieve a new token?
- The client restarts, assuming the token had a wrap_ttl attached?
How to keep data permanently available and accessible under these circumstances? That is, avoiding a long term token stored on disk.
One thing I’d like to add: a separate application/service access the same secrets. So clearly secrets cannot be tied to a specific token. Does Auto Auth support this?
Using Vault Agent Auto Auth, do secrets created with the kv engine become inaccessible under these circumstances
KV secrets are static and never expire. With KVv2, there’s no notion of a ttl/lease at all. With KVv1, you can set a TTL, but it’s purely advisory and will never result in the secret being deleted.
The dynamic secrets that can disappear as a result of a restart of an Agent with auto_auth are things like database credentials. If that happens, the client that obtained those secrets from Agent will discover the credentials don’t work (by getting an error connecting to the DB) and should handle that by getting new credentials from Vault/Agent and retrying.
Thanks for the confirmation. I’m looking to use agent auto_auth to access static secrets, so that should work indeed.