Vault (Secrets Management) Cheat Sheet
Reference for HashiCorp Vault covering the CLI, KV secrets engine, dynamic secrets, authentication methods, and policies.
CLI Basics
Core commands for interacting with a Vault server.
vault status # Check seal/init statusvault login -method=userpass username=alice # Authenticatevault secrets list # List enabled secrets enginesvault secrets enable -path=secret kv-v2 # Enable KV v2 enginevault kv put secret/app db_password=s3cr3t # Write a secretvault kv get secret/app # Read a secretvault kv delete secret/app # Soft delete (v2)
Dynamic Database Secrets
Generating short-lived, auto-expiring database credentials.
vault secrets enable databasevault write database/config/mydb \ plugin_name=postgresql-database-plugin \ connection_url="postgresql://{{username}}:{{password}}@db:5432/app" \ allowed_roles="readonly" \ username="vaultadmin" password="adminpass"vault write database/roles/readonly \ db_name=mydb \ creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \ default_ttl="1h" max_ttl="24h"vault read database/creds/readonly # Generates a new short-lived credential
Policy Definition (HCL)
Least-privilege access policy restricting path capabilities.
# app-policy.hclpath "secret/data/app/*" { capabilities = ["read", "list"]}path "database/creds/readonly" { capabilities = ["read"]}# Apply it:# vault policy write app-policy app-policy.hcl# vault token create -policy="app-policy"
Authentication Methods
Common ways clients and services authenticate to Vault.
- token- The default, most primitive auth method; every request ultimately resolves to a token
- userpass- Simple username/password authentication, mainly for humans or testing
- approle- Machine-to-machine auth using a RoleID + SecretID pair, common for CI/CD and apps
- kubernetes- Authenticates pods using their projected Kubernetes service account JWT
- aws (IAM/EC2)- Authenticates using AWS IAM credentials or EC2 instance identity documents
- ldap / oidc- Delegates authentication to an existing LDAP directory or OIDC identity provider
Core Concepts
Foundational Vault mechanisms for secrets and access control.
- Seal / Unseal- Vault starts sealed (data encrypted, inaccessible); unsealing requires a threshold of unseal keys (Shamir's Secret Sharing)
- KV v2 versioning- KV v2 engine keeps a version history of secrets and supports soft delete/undelete/destroy
- Dynamic secrets- Credentials generated on-demand with a TTL, automatically revoked on lease expiry
- Leases & renewal- Most non-token secrets are leased; clients must renew before the lease's TTL expires
- Transit secrets engine- Encryption-as-a-service ('encrypt/decrypt') without Vault storing the plaintext
- Policies- HCL rules granting capabilities (read/write/list/delete/sudo) on specific secret paths
Transit Engine (Encryption as a Service)
Encrypting/decrypting and rotating keys without Vault ever exposing key material.
vault secrets enable transitvault write -f transit/keys/app-key# Encrypt (payload must be base64)vault write transit/encrypt/app-key \ plaintext=$(base64 <<< "my secret data")# -> ciphertext: vault:v1:8SDd3WHDOjf7...# Decryptvault write transit/decrypt/app-key \ ciphertext="vault:v1:8SDd3WHDOjf7..."# Rotate the key (new writes use v2, old ciphertext still decryptable)vault write -f transit/keys/app-key/rotate# Rewrap old ciphertext to the latest key versionvault write transit/rewrap/app-key ciphertext="vault:v1:8SDd3WHDOjf7..."
PKI Secrets Engine
Standing up an internal CA and issuing short-lived TLS certificates on demand.
vault secrets enable pkivault secrets tune -max-lease-ttl=87600h pki# Generate a self-signed root CAvault write -field=certificate pki/root/generate/internal \ common_name="internal.example.com" ttl=87600h > CA_cert.crtvault write pki/config/urls \ issuing_certificates="http://vault:8200/v1/pki/ca" \ crl_distribution_points="http://vault:8200/v1/pki/crl"# Define a role constraining what can be issuedvault write pki/roles/web-role \ allowed_domains="example.com" allow_subdomains=true max_ttl="72h"# Issue a short-lived leaf certificatevault write pki/issue/web-role common_name="web.example.com" ttl="24h"
Vault Agent Auto-Auth & Templating
Letting Vault Agent handle login and secret rendering so apps never touch tokens directly.
# agent.hclpid_file = "./pidfile"auto_auth { method "kubernetes" { mount_path = "auth/kubernetes" config = { role = "web-role" } } sink "file" { config = { path = "/vault/token" } }}template { source = "/etc/vault/db.tpl" destination = "/etc/app/db.env" command = "systemctl reload app"}# Run: vault agent -config=agent.hcl
Advanced Vault Internals
Mechanisms that matter once Vault is running production workloads.
- Response wrapping- Wraps a response in a single-use token so a secret can pass through intermediaries (like CI logs) without being exposed in plaintext
- Auto-unseal- Uses a cloud KMS (AWS KMS, Azure Key Vault, GCP KMS) to unseal automatically instead of requiring manual Shamir key entry
- Performance vs DR replication- Performance replication scales reads across regions; DR replication provides a warm standby cluster for failover
- Audit devices- Every request/response is logged (hashed) to file/syslog/socket audit backends; enabling one is mandatory for compliance
- Control groups- Enterprise feature requiring multi-party authorization before a sensitive request is granted
- Root token generation- Uses the same Shamir key-share quorum as unsealing, via a nonce-based `operator generate-root` ceremony
- Secret zero problem- The bootstrapping challenge of securely giving an app its very first credential to authenticate to Vault (solved via platform-native auth like AWS IAM or Kubernetes SA JWTs)
Rekeying & Root Token Rotation
Operator-level ceremonies for rotating unseal keys and generating a new root token.
# Rekey: rotate the unseal key shares (requires current quorum)vault operator rekey -init -key-shares=5 -key-threshold=3vault operator rekey -nonce=<nonce> <unseal-key-share-1># ...repeat until threshold met# Generate a new root token via nonce + quorum of key holdersvault operator generate-root -initvault operator generate-root -nonce=<nonce> <unseal-key-share># ...repeat until threshold met, then decode the OTP-encoded token# Revoke the old root token once the new one is verifiedvault token revoke <old-root-token>
Favor dynamic secrets engines (database, AWS, PKI) over static KV secrets wherever possible — short-lived, auto-revoked credentials drastically shrink the blast radius of a leaked secret compared to long-lived static ones.