HashiCorp Vault: Secrets Management Done Right

What the problem actually looks like

The conventional approach to secrets is to store them somewhere and hope that somewhere stays controlled. Environment variables in a deployment pipeline. A shared password manager. A config file on the server. An encrypted secrets store in the cloud provider. These approaches work up to a point, but they share a common weakness: the secret exists as a static value that gets copied from wherever it lives into wherever it is needed.

Static secrets tend to persist long past their intended lifespan. A credential provisioned for a service that was decommissioned two years ago might still be valid. A database password shared between three services cannot be rotated without coordinating across all three at once. When a breach happens and you need to revoke credentials quickly, the question of what has access to what is often harder to answer than it should be.

Vault approaches this differently by treating secrets as something that should be generated on demand, issued with a defined lifespan and revoked automatically rather than stored indefinitely and passed around manually.

How Vault is structured

Vault organises everything around paths. Secrets live at paths. Auth methods are mounted at paths. Policies refer to paths. This gives Vault a consistent addressing model regardless of what kind of secret or operation is involved.

Policies are written in HCL and grant capabilities on paths. A policy that allows read on secret/data/production/* lets the token holder read any secret under that prefix. Capabilities include read, write, delete, list and create. Tokens can have multiple policies attached. The union of all capabilities from all attached policies determines what the token can do.

Secrets engines

Secrets engines are the plugins that handle different categories of secret. Each engine is mounted at a path. Some engines store data you write to them. Others generate data dynamically when you make a request.

Dynamic secrets

The most consequential thing Vault can do is generate credentials that did not exist before the request. A service asks Vault for database access. Vault calls the database, creates a user with the right permissions and hands back a username and password. That credential exists for as long as the lease is valid. When the lease expires, Vault calls the database again and drops the user.

The consequence of this model is that credential exposure becomes time-bounded. A leaked database username from a dynamic secrets engine is valid for at most as long as the lease TTL. There is no long-lived shared password to rotate. If a service is compromised, its credentials can be revoked by revoking the lease rather than rotating a password that might be stored in other places.

Authentication methods

Before Vault will issue anything, the client has to prove who it is. Auth methods handle this. Different auth methods suit different contexts. A human operator logs in differently than a Kubernetes pod.

Successful authentication returns a token. Everything in Vault from that point forward happens through the token. Tokens carry the policies that govern what the holder can do. They have a TTL. They can be set to expire after a certain number of uses. Orphaned tokens whose parent was revoked can be set to expire automatically.

The token lifecycle

Tokens are the currency of Vault access. Everything flows through them.

Seal and unseal

When Vault starts it is sealed. In a sealed state it knows where its encrypted data lives but it does not have the key to decrypt it. The data is inaccessible. No secrets can be read. No auth can succeed. Vault has to be unsealed before it can do anything.

Unsealing requires providing enough key material to reconstruct the master key. By default Vault uses Shamir secret sharing: the master key is split into N shares and any K of them must be provided together to reconstruct it. An operator with a single key share cannot unseal Vault alone. This prevents any one person from having unilateral access to the underlying key material.

In production most teams use auto-unseal. Vault delegates the unsealing step to a cloud KMS such as AWS KMS, Google Cloud KMS or Azure Key Vault. When Vault restarts it calls the KMS to decrypt the master key automatically. Human operators are no longer in the critical path for a service restart. The security boundary shifts to access control on the KMS key rather than physical custody of key shares.

Audit logging

Every request to Vault is logged. Every authentication attempt, every secret read, every failed access. The audit log records who made the request, what path they accessed, what the result was. Secret values themselves are hashed in the log rather than written in plaintext.

This is one of the more underrated features. A centralised secrets store is also a centralised audit trail for secret access. If a breach is suspected, the audit log tells you which token accessed which secret during which window. That kind of forensic capability is genuinely hard to build when secrets are scattered across environment variables, config files and a shared password manager.

Vault requires at least one audit device to be enabled before it will operate. If all audit devices are unavailable Vault stops responding to requests rather than continuing without logging. The tradeoff is deliberate: availability is sacrificed to preserve the audit guarantee.