HashiCorp Vault: Secrets Management, Encryption, and Dynamic Credentials

Vault runs as a server process with a client-server model — clients authenticate and request secrets via the Vault API (HTTPS). Architecture components: Storage Backend (where Vault persists encrypted data — Integrated Raft storage recommended for HA, also supports Consul, S3, Azure, GCS), Barrier (encryption layer — all data written to storage is AES-256-GCM encrypted with the encryption key), Unsealing (Vault starts sealed — must be unsealed with Shamir key shares or auto-unseal from a cloud KMS before it can serve requests), Active and Standby nodes (Vault Enterprise HA: one active node handles requests, standbys forward requests to active and can serve reads in performance standby mode). Initialisation: vault operator init generates the root token and unseal keys (key shares) — distribute shares to different people (5-of-7 threshold is common practice), store securely. Seal/unseal: vault operator seal locks Vault immediately (emergency shutdown), vault operator unseal requires threshold number of key holders or auto-unseal config.

Vault must know who is asking before granting access. Auth methods map external identity to Vault policies. Token auth: every authenticated identity in Vault has a token — tokens have TTLs, policies attached, and an accessor (reference without the secret). AppRole: designed for machine-to-machine auth — the application knows a RoleID (public) and retrieves a SecretID (short-lived, one-time-use) to authenticate and get a token. This separates the two credentials across deployment pipelines so no single person or system knows both. Cloud provider auth: AWS IAM auth (Vault validates the AWS caller identity — works in EC2, Lambda, ECS with IAM roles — no static credentials), Azure managed identity auth, GCP service account auth — preferred for cloud workloads. Kubernetes auth: Vault validates the Kubernetes service account JWT against the Kubernetes API — each pod authenticates with its service account token, gets a Vault token with appropriate policies. LDAP/OIDC: human user authentication via corporate directory or identity provider.

Secrets engines are the plugins that manage specific types of secrets. KV (Key-Value) secrets engine: KV v1 (simple key-value, no versioning), KV v2 (versioned — keeps configurable number of previous versions, soft delete, metadata). Use KV for static secrets that do not change frequently. Dynamic secrets are Vault's superpower: instead of storing long-lived credentials, Vault generates short-lived credentials on demand. Database secrets engine: Vault connects to PostgreSQL, MySQL, MongoDB, Oracle, and more — when an application requests credentials, Vault creates a new database user with a configurable TTL and returns the credentials. When the lease expires, Vault automatically revokes the user. AWS secrets engine: generates temporary AWS IAM credentials or STS AssumeRole tokens with a defined TTL — no long-lived AWS access keys. PKI secrets engine: issues X.509 certificates on demand — set short TTLs (24 hours) to reduce risk from certificate compromise, auto-renewal in apps using Vault Agent or cert-manager. SSH secrets engine: either CA signing (sign short-lived SSH certificates for hosts and users) or OTP (one-time passwords — no SSH key management).

Vault policies control what an authenticated identity can do. Policies are written in HCL or JSON and reference paths with capability lists: capabilities = ['read', 'list'] grants read and list on a path, create and update grant write operations, delete grants deletion, sudo allows administrative operations on root-protected paths. Policy assignment: policies are attached to auth method roles, not directly to users — when a user or application authenticates via AppRole, Kubernetes, or AWS auth, Vault looks up the role's configured policies and creates a token with those policies. Deny-by-default: if no policy grants access to a path, access is denied — you do not need explicit deny statements. Leases: every dynamic secret has a lease — a TTL after which Vault automatically revokes it. Applications can renew leases before expiry. Operators can revoke a lease immediately (incident response: leak detected — revoke the specific lease). Vault Agent: sidecar or daemon that handles authentication, lease renewal, and template rendering — applications never see Vault tokens, just the rendered secret files.