Vaults and Secret Stores

A secret store (or vault) is a centralized, hardened service whose only job is to store, control, and audit access to secrets. It replaces the scattered files and env vars that cause sprawl.

A good secrets manager provides four core capabilities:

• Centralized storage one authoritative source of truth.
• Access control fine-grained policies on who and what can read each secret.
• Audit logging a record of every access for incident response.
• Encryption secrets encrypted at rest and in transit.

Examples include HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager.

HashiCorp Vault is a popular open-source secrets manager. It organizes functionality into pluggable secrets engines mounted at paths.

• KV engine stores static key-value secrets.
• Database engine generates dynamic, short-lived DB credentials.
• PKI engine issues TLS certificates on demand.
• Transit engine encryption as a service without exposing keys.

You interact with Vault over an HTTP API or the CLI. Each path is governed by policies that decide who may read or write there.

Vault protects its data with a seal/unseal mechanism. When Vault starts, it is sealed it knows where the encrypted data is but cannot decrypt it.

The master key that decrypts the storage is itself encrypted by an unseal key. Using Shamir's Secret Sharing, that unseal key is split into multiple shards distributed to different operators.

A configurable threshold (e.g. 3 of 5 shards) must be supplied to reconstruct the key and unseal Vault. No single person can unseal it alone, which protects against insider compromise.

Before reading any secret, a client must authenticate to obtain a token. Vault supports many auth methods tailored to different identities:

• AppRole for applications and CI systems (role ID + secret ID).
• Kubernetes uses the pod service-account token.
• AWS/GCP/Azure IAM trusts the cloud platform identity.
• OIDC/LDAP for human users via SSO.

The key principle: identity comes from the platform, not a long-lived password. A Kubernetes pod proves who it is using its own service-account token no bootstrap secret to leak.

Authentication proves identity; policies decide what that identity may do. Vault policies are written in HCL and follow least privilege grant only the paths and capabilities a workload needs.

This policy lets a service read just its own database secret and nothing else:

Capabilities map to API verbs: read, create, update, delete, and list. Deny by default grant explicitly.

If you run on a single cloud, the provider's managed store removes operational burden no seal/unseal, no servers to patch:

• AWS Secrets Manager integrates with IAM and supports built-in rotation Lambdas.
• Azure Key Vault stores secrets, keys, and certificates with RBAC.
• GCP Secret Manager versioned secrets gated by IAM bindings.

Access is governed by the cloud's IAM, so a workload reads a secret using its existing role no separate password. The trade-off is vendor lock-in and weaker multi-cloud support compared to Vault.

Sometimes you do not want to store a secret at all you want to encrypt application data without your app ever holding the encryption key. Vault's Transit engine does exactly this.

The app sends plaintext to Vault, gets back ciphertext, and never sees the key. Decryption works the same way. This is called encryption as a service.

The benefit: keys live only inside Vault, can be rotated centrally, and a compromised app cannot leak a key it never possessed.

A vault is only useful if applications can consume secrets without hardcoding the path or token. Common injection patterns:

• Sidecar/agent a Vault Agent runs alongside the app, authenticates, and writes secrets to a shared in-memory volume.
• CSI driver Kubernetes mounts secrets as files via the Secrets Store CSI driver.
• SDK fetch the app calls the vault API directly at startup.

Prefer mounting to an in-memory filesystem (tmpfs) over environment variables, and avoid writing secrets to disk where they can persist.

Every read, write, and auth event in a vault should be recorded in an audit log. This is what makes secrets management defensible during an incident.

Audit logs answer the critical questions: who accessed which secret, when, and from where. Vault hashes sensitive values in logs so the log itself does not leak secrets.

Ship audit logs to a tamper-evident, separate system (SIEM) so an attacker who compromises the vault host cannot also erase the evidence of what they accessed.

A centralized store concentrates risk if the vault falls, everything falls. Harden it as your most critical asset:

• Run with TLS on all endpoints; never expose the API unencrypted.
• Keep the vault on a private network behind strict firewall rules.
• Enable auto-unseal via a cloud KMS to avoid manual shard handling, but protect that KMS key tightly.
• Use short token TTLs and renewable leases so stolen tokens expire fast.
• Patch promptly and monitor audit logs for anomalies.

The vault trades many points of failure for one extremely well-defended one.

There is no single best tool; match the store to your environment:

• Single cloud, simple needs use the native manager (AWS/Azure/GCP) for least operational overhead.
• Multi-cloud or on-prem HashiCorp Vault gives a consistent, portable abstraction.
• Need dynamic secrets or encryption-as-a-service Vault's engines are the most capable.
• Kubernetes-heavy combine a store with the CSI driver or an operator like External Secrets.

Whatever you choose, the goal is identical: one audited, access-controlled source of truth replacing scattered plaintext.

Test your understanding of Vault's protection model.

You learned how to replace scattered secrets with a centralized, audited store.

• A secret store provides centralized storage, access control, audit logging, and encryption.
• HashiCorp Vault uses pluggable secrets engines and a seal/unseal model protected by Shamir's Secret Sharing.
• Auth methods derive identity from the platform (Kubernetes, IAM, AppRole), and policies enforce least privilege.
• Cloud-native stores (AWS, Azure, GCP) trade portability for low operational overhead.
• The Transit engine offers encryption as a service so apps never hold keys.
• Inject secrets via agents or CSI to in-memory storage, log every access, and harden the vault as your most critical asset.

Next, we make secrets even safer by generating them dynamically and short-lived.