HashiCorp Vault — What Is Vault?

3 minute read

HashiCorp Vault is an identity-based secrets management system. It centrally stores, accesses, and distributes secrets like API keys, database credentials, TLS certificates, and encryption keys — with full audit logging and fine-grained access control.

The Problem Vault Solves

Every modern application needs secrets. Here’s what typically goes wrong:

┌──────────────────────────────────────────────────────┐
│              The Secrets Sprawl Problem                │
│                                                        │
│   App Code          Config Files        CI/CD Vars    │
│   ┌──────────┐     ┌──────────┐      ┌──────────┐   │
│   │ DB_PASS= │     │ aws_key= │      │ TOKEN=   │   │
│   │ "hunter2" │     │ AKIA...  │      │ ghp_...  │   │
│   └──────────┘     └──────────┘      └──────────┘   │
│                                                        │
│   ❌ No rotation    ❌ No audit      ❌ No access    │
│   ❌ In git history ❌ Plain text       control       │
└──────────────────────────────────────────────────────┘

Common pain points:

  • Secrets hard-coded in source code and committed to Git
  • Static credentials that never rotate
  • No visibility into who accessed what secret and when
  • Shared service accounts with overly broad permissions
  • Different tools for different secret types (no single pane of glass)

What Vault Provides

Vault addresses these problems with four core capabilities:

1. Centralized Secret Storage

Store all secrets in one place with a unified API:

# Store a secret
vault kv put secret/myapp db_password="s3cur3!" api_key="abc-123"

# Retrieve a secret
vault kv get secret/myapp

2. Dynamic Secrets

Generate short-lived credentials on demand instead of using static ones:

# Generate a temporary PostgreSQL credential
vault read database/creds/readonly

# Output:
# Key                Value
# ---                -----
# lease_id           database/creds/readonly/abc123
# lease_duration     1h
# username           v-token-readonly-xyz789
# password           A1b2C3d4E5-temp

The credentials are created on the fly and automatically revoked when the lease expires.

3. Encryption as a Service

Encrypt and decrypt data without managing encryption keys yourself:

# Encrypt data
vault write transit/encrypt/my-key plaintext=$(echo "sensitive data" | base64)

# Output:
# Key            Value
# ---            -----
# ciphertext     vault:v1:8SDd3WHDOjf7Mc...

4. Identity-Based Access

Fine-grained policies control who can access which secrets:

# Allow the "webapp" role to read database credentials
path "database/creds/webapp" {
  capabilities = ["read"]
}

# Deny access to admin secrets
path "secret/data/admin/*" {
  capabilities = ["deny"]
}

Vault’s Core Concepts

Concept Description
Secret Anything Vault manages — credentials, keys, certificates
Secrets Engine A pluggable component that stores/generates secrets (KV, Database, Transit, PKI)
Auth Method How clients prove their identity (Token, AppRole, OIDC, Kubernetes)
Policy An HCL document defining what paths a token can access
Token The fundamental authentication unit — every request needs one
Lease A time-limited contract for a secret, with TTL, renewal, and revocation
Audit Device Logs every Vault operation for compliance (file, syslog, socket)

How Vault Works — High Level

                    ┌───────────┐
                    │  Client   │
                    │ (CLI/API) │
                    └─────┬─────┘
                          │
                    ① Authenticate
                          │
                    ┌─────▼─────┐
                    │   Vault   │
                    │  Server   │
                    │           │
                    │ ② Check   │
                    │   Policy  │
                    │           │
                    │ ③ Process │
                    │   Request │
                    │           │
                    │ ④ Audit   │
                    │   Log     │
                    └─────┬─────┘
                          │
                    ⑤ Return Secret
                          │
                    ┌─────▼─────┐
                    │  Client   │
                    └───────────┘
  1. Authenticate — Client proves identity via an auth method
  2. Check Policy — Vault verifies the token has the required capabilities
  3. Process Request — The appropriate secrets engine handles the request
  4. Audit Log — The operation is recorded to all enabled audit devices
  5. Return Secret — The secret (or error) is returned to the client

Vault API-First Design

Every Vault operation is an HTTP API call. The CLI and UI are just wrappers:

# CLI command
vault kv get secret/myapp

# Equivalent API call
curl --header "X-Vault-Token: $VAULT_TOKEN" \
     http://127.0.0.1:8200/v1/secret/data/myapp

Example API response:

{
  "request_id": "abc123",
  "data": {
    "data": {
      "db_password": "s3cur3!",
      "api_key": "abc-123"
    },
    "metadata": {
      "created_time": "2024-01-15T10:30:00Z",
      "version": 1
    }
  }
}

Real-World Use Cases

Use Case How Vault Helps
Database credential rotation Dynamic secrets with automatic lease expiry
TLS certificate management PKI engine issues and rotates certificates
CI/CD pipeline secrets AppRole auth with scoped policies per pipeline
Kubernetes workloads Agent Injector delivers secrets to pods automatically
Data encryption Transit engine encrypts data without exposing keys
Compliance auditing Every secret access is logged with request details
Multi-cloud secrets Single API for AWS, Azure, and GCP credentials

Quick Reference

Item Details
Official site vaultproject.io
License BSL (Business Source License) since v1.14+
Latest version 1.15+ (used throughout this tutorial)
Default port 8200 (HTTP API and UI)
Config language HCL (HashiCorp Configuration Language)
Storage options Raft (integrated), Consul, cloud-managed

Next: Vault Architecture

You may also enjoy