Vault Associate: Access Secrets

Static versus dynamic

Static secrets (KV) are stored by Vault. Dynamic secrets are generated on demand by an engine (database, AWS, PKI) and always return lease_id, lease_duration, and renewable. Reading database/creds/app creates a real database user - that is why every dynamic read produces a lease you must manage.

KV version 1 versus 2

KV v1 lives at secret/<path>. KV v2 adds versioning and metadata and changes the API paths: data operations use secret/data/<path>, list and metadata use secret/metadata/<path>, and soft-delete, undelete, and destroy use secret/delete, secret/undelete, secret/destroy. The CLI hides most of this:

vault kv put secret/app db=prod
vault kv get -version=2 secret/app
vault kv delete -versions=1 secret/app   # soft delete, recoverable
vault kv destroy -versions=1 secret/app  # permanent

Check-and-set (cas=) prevents blind overwrites and is only available on v2.

Cubbyhole

cubbyhole/ is a per-token private store; its contents vanish when the token is revoked or expires.

Traps

• Policies must reference API paths, not CLI shorthand - a v1 policy 403s on a v2 mount.
• Deleting the latest version does not erase data; destroy does.
• KV reads carry no lease and cannot be renewed.
• vault kv get returns metadata plus data on v2; check version and deletion_time.

Rule of thumb: if the response contains a lease_id, the secret is dynamic - plan renewal and revocation; if it does not, it is static KV.