HashiCorp Vault

HashiCorp Vault is a tool for centrally managing secrets — API keys, database credentials, certificates, encryption keys — and controlling access to them. Instead of secrets scattered across config files, environment variables, and CI systems (each a leak waiting to happen), applications authenticate to Vault and request the secrets they need, with every access authenticated, authorized, audited, and time-limited.

Its most distinctive capability is dynamic secrets: rather than storing a long-lived database password, Vault generates a unique, short-lived credential on demand and automatically revokes it after use. A leaked credential that expires in an hour is a far smaller problem than a static password that's been in a .env file for two years. Combined with encryption-as-a-service and pluggable authentication, Vault became the reference tool for secrets management at scale — and a natural component of zero-trust architectures.

TL;DR

Why Centralized Secrets Management

The problem Vault solves is secret sprawl:

Static secrets are dangerous precisely because they're static and everywhere: hard to rotate, impossible to audit, and devastating when leaked. Vault's model — centralize, authenticate every access, make secrets short-lived, log everything — turns a leaked credential from a standing disaster into a bounded, detectable incident.

Core Concepts

Secrets Engines

Vault's functionality is modular via secrets engines, each handling a kind of secret:

Dynamic Secrets: The Differentiator

This is what sets Vault apart from a password vault. Instead of storing one database password everyone shares, Vault's database engine holds admin credentials and, when an app requests access, creates a brand-new database user scoped and time-limited, hands it over, and deletes it when the lease expires:

The security wins are large: every app instance gets distinct credentials (so a leak is traceable and isolated), credentials are short-lived by default (limiting exposure window), and rotation is automatic (no more "the shared prod password hasn't changed since 2021"). The same model applies to cloud IAM, SSH, and certificates.

Authentication Methods

Before getting secrets, a client must prove who it is. Vault supports pluggable auth methods so workloads (not humans typing passwords) authenticate by their existing identity:

On success, Vault issues a token scoped by policies (least-privilege rules: "this app may read secret/data/app/db and nothing else"). This is zero-trust applied to secrets — identity-based, least-privilege, per-request.

Encryption as a Service (Transit)

The Transit engine lets applications encrypt and decrypt data without ever handling the encryption keys. The app sends plaintext to Vault, gets ciphertext back (and vice versa); the keys stay in Vault, centrally managed and rotatable. This means developers get strong encryption without the perilous job of managing keys themselves — and key rotation happens in one place without re-encrypting everything manually.

Leases, Revocation, and the Seal

Vault vs Alternatives

The trade-off is real: cloud secret managers (AWS Secrets Manager, GCP Secret Manager) are far simpler if you're all-in on one cloud and mostly need static-secret storage with rotation — no infrastructure to run. Vault wins when you need dynamic secrets, encryption-as-a-service, multi-cloud neutrality, or its depth of engines and policies — at the cost of operating a stateful, security-critical service. (Note: raw Kubernetes Secrets are base64, not encrypted, by default — a common misconception; they need encryption-at-rest configured and are the weakest option.) Many orgs use Vault as the central engine and cloud managers or External Secrets Operator to bridge into specific platforms.

Common Mistakes

Treating Vault as Just a Password Store

Using Vault only for static KV storage misses its point — dynamic secrets, short TTLs, and auto-revocation are where the security value is. If every secret in your Vault is a long-lived static string, you've bought complexity without the benefit; a cloud secret manager might serve you better.

Long-Lived Tokens and Secrets

Configuring huge TTLs (or infinite) recreates the static-secret problem inside Vault. Embrace short leases and renewal — the whole model assumes secrets are temporary. Long-lived root tokens lying around are a particular danger.

Ignoring the Ops Burden

Vault is stateful, security-critical infrastructure: it needs high availability (a Vault outage can halt every app that needs secrets), careful unseal procedures, backups, and upgrade discipline. Teams that deploy it casually get bitten by seal/unseal confusion and single-point-of-failure outages. Plan for HA and operational maturity — or use HCP Vault (managed).

Overly Broad Policies

Granting apps wide access ("read all of secret/") defeats least privilege — a compromised app can then read everything. Scope policies tightly to exactly the paths each identity needs, mirroring the zero-trust principle.

Root Token Sprawl

The root token can do anything; it should be generated for setup, used minimally, and revoked. Using or storing root tokens for routine operations is a severe risk — everything should run through scoped, least-privilege tokens.

FAQ

Do I need Vault, or is a cloud secret manager enough?

If you're on one cloud and mainly need to store and rotate static secrets, the cloud's secret manager (AWS Secrets Manager, etc.) is simpler and managed — often the right call. Reach for Vault when you need dynamic secrets, encryption-as-a-service, multi-cloud/on-prem neutrality, or its policy depth. Don't take on running Vault for problems a cloud manager already solves for you.

What makes dynamic secrets better than static ones?

Static secrets are long-lived, shared, hard to rotate, and untraceable when leaked. Dynamic secrets are generated per-request, unique per consumer, short-lived, and auto-revoked — so a leak is isolated, traceable, and expires quickly. It converts "a leaked password is a standing crisis" into "a leaked credential is dead in an hour." That's the core security upgrade.

How do applications authenticate to Vault without a chicken-and-egg secret?

Via identity-based auth methods that use credentials the workload already has: a Kubernetes pod uses its service account token, a cloud VM uses its IAM role, CI uses AppRole. Vault verifies that existing identity rather than requiring a pre-shared secret — solving the "secret zero" problem that plagues naive setups.

Is Vault hard to operate?

It's real infrastructure — stateful, security-critical, needing HA, backups, unseal procedures, and upgrade care. That operational weight is Vault's main cost. HCP Vault (HashiCorp's managed offering) removes much of it. Note also the licensing change: Vault moved to the BSL license (like Terraform), with OpenBao as the open-source fork — relevant if open-source governance matters to you.

How does Vault relate to zero trust?

Directly — Vault implements zero-trust principles for secrets: every access is authenticated by identity, authorized by least-privilege policy, time-limited, and audited. Short-lived dynamic credentials are the secrets-layer expression of "never trust, always verify, and grant the minimum for the shortest time."

Related Topics

References