What is HashiCorp Vault and How Does It Work?
Understand HashiCorp Vault — unsealing, auth methods, policies, and dynamic secrets — with a DevOps interview-ready explanation.
Expected Interview Answer
HashiCorp Vault is a centralized secrets-management system that securely stores, dynamically generates, and tightly controls access to credentials, encryption keys, and certificates, sealing all data at rest with an encryption key that must be unsealed before Vault can serve requests.
Vault stores secrets in a backend (like an encrypted key-value store or an integrated Raft storage), and every secret is encrypted using a master key that is itself split via Shamir’s Secret Sharing so no single operator can unseal Vault alone — a quorum of key shares is required. Clients authenticate to Vault using an auth method (Kubernetes service account tokens, AWS IAM roles, LDAP, or AppRole for CI/CD), and Vault issues a short-lived token bound to specific policies that define exactly which secret paths that identity may read or write. Beyond static key-value secrets, Vault’s dynamic secrets engines can generate on-demand, time-limited credentials for databases, cloud IAM, or SSH — for example, issuing a Postgres username/password pair with a 1-hour TTL that Vault automatically revokes when it expires, so no long-lived database password ever needs to be shared or rotated manually. Vault also provides the Transit engine for encryption-as-a-service, letting applications encrypt/decrypt data without ever handling the raw encryption key themselves.
- Centralizes and encrypts all secrets in one auditable system
- Issues dynamic, short-lived credentials instead of static passwords
- Enforces fine-grained, policy-based access per identity
- Provides encryption-as-a-service without exposing raw keys
AI Mentor Explanation
Vault is like a stadium’s central equipment vault that requires two of three senior officials to insert their keys together before the vault door opens at all — no single person can raid it alone. Once open, each player is issued only the specific gear locker code assigned to their role for that match, not a master code to every locker. For a one-off net session, a trialist is issued a temporary access code that self-destructs after two hours, rather than a permanent key. The vault logs every single access request so officials know exactly who entered and when.
Step-by-Step Explanation
Step 1
Unseal Vault
A quorum of key shares (Shamir’s Secret Sharing) is combined to decrypt the master key and bring Vault online.
Step 2
Authenticate a client
A service or user authenticates via an auth method (Kubernetes, AWS IAM, AppRole, LDAP) and receives a scoped token.
Step 3
Enforce policy
Vault checks the token’s attached policy to determine which secret paths and operations that identity is permitted.
Step 4
Issue or return secrets
Vault returns a static secret or dynamically generates a short-lived credential, then auto-revokes it at TTL expiry.
What Interviewer Expects
- Understanding of the seal/unseal mechanism and Shamir’s Secret Sharing
- Knowledge of auth methods and policy-based, least-privilege access
- Ability to explain dynamic secrets and automatic TTL-based revocation
- Awareness of the Transit engine for encryption-as-a-service
Common Mistakes
- Thinking Vault only stores static key-value secrets, missing dynamic secrets engines
- Not understanding that Vault must be unsealed before serving any requests
- Confusing authentication (who you are) with authorization (what policy allows)
- Assuming Vault tokens are permanent instead of TTL-bound and renewable
Best Answer (HR Friendly)
“Vault is a secure central system for storing and issuing our secrets, like database passwords and API keys, instead of scattering them across config files. It can even generate temporary, short-lived credentials on demand that expire automatically, so if something ever leaks, the exposure window is tiny, and we always know exactly who accessed what through Vault’s audit logs.”
Code Example
# Enable the database secrets engine
vault secrets enable database
# Configure the connection to Postgres
vault write database/config/mydb \
plugin_name=postgresql-database-plugin \
connection_url="postgresql://{{username}}:{{password}}@db:5432/app" \
allowed_roles="readonly"
# Define a role with a 1-hour TTL credential
vault write database/roles/readonly \
db_name=mydb \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD \"{{password}}\" VALID UNTIL \"{{expiration}}\";" \
default_ttl="1h" max_ttl="4h"
# Request a short-lived credential
vault read database/creds/readonlyFollow-up Questions
- How does Vault’s unseal process differ from normal authentication?
- What is the difference between static and dynamic secrets engines in Vault?
- How would you integrate Vault with a Kubernetes deployment?
- What happens if a Vault token expires mid-operation?
MCQ Practice
1. What must happen before Vault can serve any secret requests?
Vault stores data encrypted at rest and requires a quorum of Shamir’s Secret Sharing key shares to unseal the master key before it can operate.
2. What is a dynamic secret in Vault?
Dynamic secrets are generated on demand for a specific request, carry a TTL, and are automatically revoked by Vault when that TTL expires.
3. What determines which secret paths a Vault client can access?
Vault enforces fine-grained access through policies attached to tokens, which specify exactly which paths and operations are permitted.
Flash Cards
What is Vault? — A centralized secrets manager that stores, dynamically generates, and controls access to credentials and keys.
How is Vault unsealed? — A quorum of Shamir’s Secret Sharing key shares combine to decrypt the master key.
What are dynamic secrets? — On-demand, short-lived credentials that Vault automatically revokes at TTL expiry.
What is the Transit engine? — Vault’s encryption-as-a-service feature, letting apps encrypt/decrypt without handling raw keys.