Sealing, Secrets Engines & Dynamic Secrets

Why Not Just Use Config Files?

HashiCorp Vault centralizes storage of and access control over secrets — API keys, passwords, certificates. Secrets hardcoded in source or plain config files tend to leak via git history, backups, or logs, are hard to rotate without a redeploy, and leave no audit trail. Vault addresses all three.

Sealed vs. Unsealed

A sealed Vault has its storage backend encrypted and inaccessible. Unsealing requires a threshold of unseal key shares (via Shamir's Secret Sharing — e.g. 3 of 5 shares, so no single person holds the whole key) — or, in production, an auto-unseal mechanism using a cloud KMS (AWS KMS, Azure Key Vault), which removes the operational burden of gathering key holders every restart while still keeping the master key encrypted.

Secrets Engines

Vault's functionality is organized into pluggable secrets engines mounted at different paths: KV (key-value) for static secrets you write yourself, database for dynamically generated credentials, PKI acting as an internal certificate authority, transit for encryption-as-a-service, and cloud-provider-specific engines (AWS, Azure, GCP).

vault kv put secret/myapp/db password="s3cr3t"
vault kv get secret/myapp/db

# dynamic database credential, unique + short-lived
vault read database/creds/readonly-role

Dynamic Secrets & Leases

Unlike a KV secret you wrote yourself, a dynamic secret (e.g. from the database engine) is generated fresh per request, unique, and time-bound by a lease — Vault can auto-revoke it when the lease expires. A leaked dynamic credential has a naturally bounded blast radius, versus a static password that stays valid until someone notices and rotates it manually.

Transit — Encryption as a Service

The transit engine lets an application send Vault plaintext to encrypt (or ciphertext to decrypt) using a key Vault manages internally — the application never handles or stores the raw encryption key itself.