Part 2 · 2 chapters · ~12 min

HashiCorp Vault

Vault's architecture (storage, seal and unseal, tokens, policies), secrets engines (KV, database, PKI, transit, cloud), auth methods (Kubernetes, AWS IAM, OIDC, AppRole), dynamic database credentials and leases, transit encryption as a service, Vault Agent and the sidecar injector, and running Vault itself in high availability.

Architecture, engines and auth methods

concept	what it is
seal / unseal	Vault's storage is encrypted; on start it is sealed until the master key is reconstructed (Shamir shares, or auto-unseal via a cloud KMS or HSM)
storage	integrated Raft storage (recommended), or Consul; HA with one active node and standbys
auth methods	how a client proves identity: Kubernetes, AWS/GCP/Azure IAM, OIDC for humans, AppRole for machines, TLS certs
tokens and policies	a login yields a token with policies (HCL paths and capabilities: read, create, update, deny)
KV engine	static secrets, versioned (kv-v2)
database engine	dynamic, short-lived database users
PKI engine	an internal certificate authority issuing short-lived TLS certificates
transit engine	encryption as a service: apps send plaintext, get ciphertext, never hold keys; key rotation and rewrap

code

# policy: the ledger service may get database creds and use one transit key
path "database/creds/ledger-rw"   { capabilities = ["read"] }
path "transit/encrypt/pii"        { capabilities = ["update"] }
path "transit/decrypt/pii"        { capabilities = ["update"] }

# encrypt a BVN without the app ever holding the key
vault write transit/encrypt/pii plaintext=$(echo -n "22212345678" | base64)
# → ciphertext: vault:v3:8SDd3... (the key version is part of the ciphertext)

Dynamic credentials, leases and the agent

Vault Agent (or the Vault Agent sidecar injector on Kubernetes, or the Vault Secrets Operator) handles login, renewal and rendering secrets to a file the app reads, so application code only reads a file and reloads on change. That keeps Vault logic out of every codebase.

DYNAMIC DATABASE CREDENTIALS FROM VAULT

a pod authenticates, gets a username and password that exist for one hour, and never sees a long-lived secret

swipe the figure sideways, or tap expand for full screen

1/5

authenticate

The pod proves who it is with its Kubernetes service account token; Vault checks it with the Kubernetes API (the kubernetes auth method). No secret was needed to get a secret.

identity from the platform, not a stored passwordkubernetes, AWS IAM, OIDC auth methods