HashiCorp Vault guide

What Vault does in production

Vault is a secrets management system. Instead of copying passwords into .env files or Kubernetes Secrets that never rotate, apps and operators request credentials at runtime. Vault encrypts data at rest, audits access, and issues leases so secrets expire automatically.

The swiss army knife of secret storage

Vault is often called the swiss army knife of secrets management because one platform covers many patterns through pluggable secrets engines and auth methods — not just a password vault. Teams adopt it once and reuse it across use cases instead of bolting together separate tools.

Common applications:

• Static app secrets — API keys, webhook tokens, config in KV; versioned and audited
• Dynamic database credentials — short-lived Postgres/MySQL users minted per app or job
• TLS / PKI — internal certificate authority; issue and renew certs for services
• Encryption as a service (Transit) — encrypt sensitive fields at rest in your DB without holding the master key in the app
• Cloud IAM credentials — temporary AWS/GCP access keys for workloads
• CI/CD and automation — AppRole or JWT auth for pipelines to fetch secrets at deploy time
• Kubernetes — inject secrets into pods via Agent or CSI; workloads authenticate with service accounts
• SSH access — one-time passwords or signed SSH certificates instead of shared keys
• Secure handoff — response wrapping to pass a secret to another party without exposing it in chat or tickets

You enable only the engines you need; a small deployment might use KV alone, while a platform team might run database, PKI, Transit, and Kubernetes auth together.

Sealed vs unsealed

On startup (or after restart), Vault is sealed — the encryption key protecting stored data is not in memory; all API calls fail. Operators unseal by providing key shards (Shamir secret sharing) or via auto-unseal (cloud KMS). This is deliberate: stolen disk snapshots are useless without unseal material.

Check status: vault status — look for Sealed: true/false. After unseal, initialize only once per cluster (vault operator init); store unseal keys and root token securely offline.

How a secret read works

1. Authenticate — client proves identity (token, AppRole, K8s SA, LDAP, etc.)
2. Token — Vault returns a token with attached policies
3. Request — client reads secret/data/myapp/config (KV v2 example)
4. Policy check — ACL policies allow or deny the path and operation
5. Response — secret data returned; lease TTL starts if applicable

Core concepts

• Mount path — prefix where an engine is enabled (secret/, database/)
• Secrets engine — plugin that stores or generates secrets
• Policy — HCL document defining allowed paths and capabilities
• Token — identity for API access; can be renewable and TTL-bound
• Lease — lifetime of a secret or token; renew or revoke
• Audit device — log every request (file, syslog, socket)

Common secrets engines

• KV (v1/v2) — static key/value secrets; v2 supports versioning and soft delete
• Database — dynamic DB credentials (Postgres, MySQL) with TTL
• PKI — issue TLS certificates on demand
• Transit — encrypt/decrypt data without exposing the key
• AWS/GCP — dynamic cloud IAM credentials

KV v2 paths use data/ for reads: vault kv get secret/myapp maps to mount secret, path myapp internally.

Authentication methods

• Token — bootstrap; child tokens inherit policies
• AppRole — machine auth with role_id + secret_id (CI/CD, VMs)
• Kubernetes — pods authenticate via service account JWT
• LDAP / OIDC / userpass — human operators

On Kubernetes, the Vault Agent Injector or CSI driver mounts secrets into pods. See the Kubernetes lab for pod debugging when injection fails.

Policies (least privilege)

Policies use path rules with capabilities: create, read, update, delete, list, sudo. Example: an app policy allows read on secret/data/myapp/* only. Deny-by-default — permission denied means wrong token, policy, or path (including v1 vs v2).

Storage and HA

Modern deployments use integrated storage (Raft) for HA — multiple Vault nodes, one active leader. Older setups used Consul as storage backend. Back up Raft snapshots regularly; unseal keys remain required after restore unless auto-unseal is configured.

Vault vs flat files and Kubernetes Secrets

Plain env vars and git-committed configs leak in breaches and are hard to rotate. Kubernetes Secrets are base64-encoded, not encrypted by default at rest. Vault adds central policy, audit logs, dynamic credentials, and rotation — at the cost of operating another critical service (availability, unseal, upgrades).

Key files and environment

• Config — /etc/vault.d/vault.hcl
• Data (Raft) — /opt/vault/data/ (path in config)
• CLI env — VAULT_ADDR, VAULT_TOKEN
• Service — vault systemd unit
• Logs — audit log path from config; server logs via journal

Learning resources

• Vault documentation — developer.hashicorp.com/vault/docs
• Getting started — Vault tutorials
• KV secrets engine — KV docs
• Policies — Policies concepts
• HashiCorp certification — HashiCorp Certified: Vault Associate — official exam validating Vault concepts and operations; SadServers scenarios complement hands-on practice before the test