Vault — Basics

HashiCorp Vault — Basics

What it is

Secret management + identity-based access. Stores secrets, generates dynamic credentials, manages encryption keys. Open-source core + paid Enterprise features.

Core concepts

• Secret engine — pluggable backend (KV, database, AWS, PKI, transit, ssh, etc.).
• Auth method — how clients authenticate (token, AppRole, K8s, AWS IAM, JWT/OIDC, LDAP, GitHub).
• Policy — HCL document granting/denying paths.
• Token — capability bearer (root, periodic, renewable).
• Path — every Vault op is on a path (secret/data/db, database/creds/readonly).
• Lease — TTL on dynamic secrets; auto-revoked.
• Seal/unseal — Vault must be unsealed (with Shamir keys or auto-unseal via cloud KMS) to operate.
• Audit device — logs all requests/responses for compliance.

Secret engines

KV v2 (versioned static secrets)

vault kv put secret/api/db password=foo
vault kv get secret/api/db
vault kv get -version=2 secret/api/db

Database (dynamic creds)

• Vault generates per-request DB user with TTL. Revoked when lease expires.
• Supports Postgres, MySQL, MongoDB, Snowflake, etc.

AWS

• Generate temporary IAM creds dynamically.
• Useful for Lambda, batch jobs needing assumed role + STS rotation.

PKI

• Vault as a CA. Issues short-lived certs for mTLS.

Transit (encryption-as-a-service)

• App sends plaintext → Vault encrypts → app stores ciphertext.
• Key never leaves Vault.
• Used for envelope encryption.

SSH

• Signed SSH certs; ephemeral access without long-lived keys.

Auth methods

• Token: simple, limited use cases.
• AppRole: machines auth with role_id + secret_id (best fit for CI).
• Kubernetes: pods authenticate via SA JWT.
• AWS IAM: instance profile / IAM role auth.
• JWT/OIDC: integrate with GitHub Actions (OIDC), GCP, Azure, etc.
• LDAP / OIDC for humans.
• TLS certificates.

Policy example

path "secret/data/api/*" {
  capabilities = ["read"]
}
path "database/creds/api-readonly" {
  capabilities = ["read"]
}
path "transit/encrypt/api" {
  capabilities = ["update"]
}

CLI essentials

vault status
vault login -method=oidc
vault token create -policy=api -period=24h
vault kv put  secret/db password=p
vault kv get  secret/db
vault read    database/creds/readonly
vault write   transit/encrypt/api plaintext=$(echo -n "data" | base64)
vault list    secret/metadata/
vault policy  list
vault policy  read api
vault policy  write api ./api.hcl
vault audit   enable file file_path=/var/log/vault.log

Architecture

• HA via consensus (Raft built-in, or Consul as backend).
• Multi-region (Enterprise: Replication, Performance Standby).
• Auto-unseal via cloud KMS recommended (AWS KMS, GCP KMS, Azure KV).

Common interview Qs

1. Static vs dynamic secrets? Static = stored, retrieved (KV). Dynamic = generated on demand with lease (DB, AWS).
2. Why dynamic creds? Short-lived; revoke compromised; per-request audit; no rotation drama.
3. AppRole flow? App has role_id (in code/env) + secret_id (delivered via trusted broker). Login → token. Limit scope via policies.
4. Vault unseal? Shamir N-of-M key shares; auto-unseal via cloud KMS for prod.
5. K8s auth? Pod’s service-account JWT presented to Vault; Vault validates with K8s API; binds to role with policies.
6. What is transit engine for? Encrypt/decrypt without storing keys in app. Sign/verify too.
7. Secret zero problem? How does the first secret (Vault token) get to the app? Bootstrap via cloud IAM (AWS IAM auth, K8s SA), short-lived OIDC, etc.

Anti-patterns

• Long-lived root tokens.
• Apps using same token across services.
• No audit logging.
• Storing static secrets when dynamic engines exist.
• Vault as just a KV store — missing the dynamic secret value.
• No backup / restore plan for Raft state.
• Single Vault node in prod.