Store and read a KV secret
Run a local dev Vault, enable KV v2 at a custom path, write one API key, and read it back using CLI.
DevOps & Tooling / Knowledge library
HashiCorp Vault
centralized secrets and encryption lifecycle manager
Why learn HashiCorp Vault?
Vault reduces secret sprawl by centralizing storage, access control, dynamic credential issuance, and encryption-as-a-service. It helps teams avoid hardcoded keys, rotate secrets safely, and enforce least privilege with auditability.
Where it came from
2015: Vault was introduced by HashiCorp as a tool for secrets and data protection. Early adoption grew around dynamic secrets for databases and cloud APIs. Integrated Storage (Raft) reduced dependency on external storage backends for many teams. Vault Agent and Kubernetes integrations improved secret delivery patterns. 2023: HashiCorp changed licensing to BUSL; OpenBao emerged as an open governance fork.
- 2015: Vault was introduced by HashiCorp as a tool for secrets and data protection.
- Early adoption grew around dynamic secrets for databases and cloud APIs.
- Integrated Storage (Raft) reduced dependency on external storage backends for many teams.
- Vault Agent and Kubernetes integrations improved secret delivery patterns.
- 2023: HashiCorp changed licensing to BUSL; OpenBao emerged as an open governance fork.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Run a local dev Vault, enable KV v2 at a custom path, write one API key, and read it back using CLI.
- Create a policy that allows read-only access to one KV path and denies list/read elsewhere. Verify with a scoped token.
- Configure AppRole for a sample service, fetch a token using role_id and secret_id, then read only authorized secrets.
- Enable Transit, encrypt a plaintext payload, decrypt it, and explain why data is never stored in Transit by default.
- Configure the database secrets engine for short-lived credentials and demonstrate automatic expiration/rotation behavior.
More ways to practice
Least-privilege policy
Create a policy that allows read-only access to one KV path and denies list/read elsewhere. Verify with a scoped token.
AppRole login flow
Configure AppRole for a sample service, fetch a token using role_id and secret_id, then read only authorized secrets.
Transit encryption service
Enable Transit, encrypt a plaintext payload, decrypt it, and explain why data is never stored in Transit by default.
Dynamic database credentials
Configure the database secrets engine for short-lived credentials and demonstrate automatic expiration/rotation behavior.
Documentation and sources
- Vault Docs (developer.hashicorp.com)
- Vault Tutorials (developer.hashicorp.com)
- Vault API Docs (developer.hashicorp.com)
- OpenBao Project (openbao.org)
Catalog research notes
- Integrated Storage (Raft) is now a common default for self-managed clusters.
- After HashiCorp’s 2023 BUSL license move, the OpenBao community fork launched under the Linux Foundation.
- Managed Vault offerings continue improving operational automation (upgrades, backups, observability).
- Cloud-native auth patterns (OIDC, Kubernetes, JWT) are increasingly emphasized in production designs.
Connect the ideas
Explore next
Real World Example
Automated Financial Microservice Credential Lifecycle
A high-frequency trading platform managing distributed microservices that interact with multiple external banking APIs.
The business problem
The platform suffers from manual credential rotation overhead and the risk of long-lived static API keys being leaked, leading to potential unauthorized access to financial gateways.
How this topic solves it
Vault acts as a centralized secrets manager that replaces static credentials with dynamic, short-lived tokens generated on-demand. By integrating with Vault's secrets engines, the platform ensures that every microservice receives unique, time-bound credentials that automatically expire, effectively neutralizing the impact of a credential leak.
- Enable the appropriate secrets engine for the target cloud or database provider.
- Configure a role in Vault that defines the permissions and Time-To-Live (TTL) for generated credentials.
- Authenticate the microservice using a secure identity method like AppRole or Workload Identity Federation.
- Request dynamic credentials from the Vault API using the authenticated service identity.
- Implement automated renewal logic within the application to refresh tokens before the TTL expires.
This diagram illustrates the request-response cycle between a microservice and Vault to obtain temporary access.
Client requesting access
Centralized secrets manager
External resource
- Microservice → Authenticates and requests credentials → Vault
- Vault → Issues dynamic, short-lived token → Microservice
- Microservice → Accesses API with temporary token → Banking API
Expected business outcome
The organization achieves a zero-trust posture where static secrets are eliminated, significantly reducing the attack surface and removing the manual burden of rotating credentials across dozens of services.
Limitations and checks
The primary trade-off is increased architectural complexity and a hard dependency on Vault availability. If the Vault cluster becomes unreachable, microservices cannot refresh their credentials, leading to service outages. To monitor this, administrators must track the 'vault.token.lookup-self' latency and the 'vault.lease.count' metrics to ensure the cluster is not hitting capacity limits.