Static secrets — a database password that stays valid for months or years — are a liability the moment they're created, because every day they exist is another day they could be leaked and still be usable. Vault's core value proposition is minimizing how long a secret is valid at all.
Static secrets vs. dynamic secrets
Most secret managers store and serve static values — you still have to rotate them yourself, on your own schedule. Vault's dynamic secrets feature can generate credentials on demand, scoped to a short lease, and automatically revoke them when the lease expires. A database credential that's valid for 15 minutes and unique per request is far less valuable to an attacker than a static password used by every instance of your application indefinitely.
Core concepts
- Secrets engines — pluggable backends for different secret types (key-value storage, dynamic database credentials, PKI certificate issuance, cloud provider credentials).
- Leases — every dynamically-generated secret has an expiration. Vault tracks and can automatically revoke it when the lease ends.
- Policies — fine-grained rules defining exactly which paths (and therefore which secrets) a given identity can read, write, or manage.
- Authentication methods — how a service or user proves its identity to Vault in the first place (tokens, cloud IAM roles, Kubernetes service accounts, and others).
A simple example: dynamic database credentials
Instead of an application reading a static DB_PASSWORD from configuration, it authenticates to Vault (e.g., via its Kubernetes service account) and requests a database credential. Vault creates a new database user on the fly, scoped to a short lease, and returns those credentials. When the lease expires, Vault revokes that specific user — no manual rotation, and a much smaller window of usefulness if the credential ever leaked.
When the operational overhead is worth it
Running Vault (or a managed equivalent) is itself infrastructure you now need to secure, monitor, and keep available — it becomes a critical dependency for nearly everything else. For a small team with a handful of services, this overhead may outweigh the benefit. The tradeoff shifts once you have multiple services and environments needing scoped, auditable access to different secrets, and static secret rotation has become a genuine operational burden.
Getting started incrementally
You don't need to migrate every secret on day one. Start with your highest-value use case — commonly database credentials or cloud provider access — and expand as the operational pattern proves itself, rather than attempting a full migration up front.