KV, database, and wrapping secrets | Vault Associate 003: secrets and operations

Concept and mechanism

The secrets engine defines what managing a secret means. KV stores arbitrary values; a database engine can issue dynamic accounts or manage a password for an account mapped through a static role. Do not confuse a database static role with a password stored in KV: the former integrates destination rotation while KV alone does not perform that external change. For dynamic accounts, define creation, privileges, validity, and revocation according to plugin and database capabilities. For a legacy system requiring a fixed username, coordinate rotation with every consumer and validate how passwords reload. One value copied into several systems creates several operational dependencies.

Guided application

KV v2 adds versions and soft deletion. A soft-deleted version can be recovered; destroy purges that version’s data. To avoid concurrent overwrites, CAS compares the expected version with the current one. If both clients read 6 and one writes 7, the other should not force its old write: reread and reconcile. CAS zero means create only if the key does not exist rather than ignore conflicts. For delivery, response wrapping puts a response behind a single-use token with its own TTL. The recipient can validate origin before unwrapping. An intermediary unwrapping for debugging consumes that use and learns the secret; the flow needs correction and exposure needs an appropriate response.

IN PRACTICE

A wrapping token still within TTL may already have been consumed.

Common pitfalls

KV as external rotation; soft delete as destroy; CAS zero as override; wrapping as reusable token.

Related topics: Authentication and identity · Policies, paths, and capabilities · Tokens, leases, and renewal

Take this idea with you

Choose the engine lifecycle and preserve it through to the consumer.

Create account

Reference: Database secrets engine · Vault Associate (003); product version tested: Vault 1.19