Where secrets live

A secret store is a service that holds secrets, limits who can read them, and logs every read. Three patterns cover most teams: a managed cloud secret manager, HashiCorp Vault, and plain config. A Kubernetes Secret looks like a store, but by default it is not one.

Three patterns

How Vault makes dynamic secrets

Vault works in two steps. The app authenticates, using a Kubernetes service account, cloud IAM or AppRole. Then it reads a path that its policy allows. For databases, Vault creates a unique Postgres user with a time limit. When the lease ends, Vault drops the user.

After the app authenticates with its Kubernetes service account, it reads the credential path:

vault read database/creds/payments-ro

The output looks like this:

username        v-k8s-payments-...
password        ...
lease_duration  1h

This changes the problem. A stolen password is no longer a shared secret that lives forever. It is a credential that dies within an hour and was never shared.

Cloud secret managers work the same way with workload identity. The task role may read one secret and nothing else. The app fetches the value at startup, or caches it briefly. It never bakes the value into the image.

Kubernetes Secrets are not a vault

A Kubernetes Secret is base64-encoded data in etcd. Base64 is encoding, not encryption. Anyone who can read secrets in the namespace, or read etcd, can decode them. They also end up in etcd backups.

Common fixes:

• Encrypt etcd at rest with a key from a cloud KMS.
• External Secrets Operator syncs values from AWS, GCP or Vault into Kubernetes. The real source of truth stays outside the cluster.
• Sealed Secrets or SOPS store encrypted values in git. Only the cluster can decrypt them, so you still need to manage keys.
• Mounted secrets from a CSI driver or the Vault Agent injector live as in-memory files, not as etcd objects.

Never commit raw secrets to git, even briefly.

Common mistakes

• Assuming Kubernetes Secrets are encrypted. They are encoded unless you turn on etcd encryption.
• Mixing secrets into plain config. Use the store for anything that grants access.
• Two sources of truth. Pick one store per class of secret.

Check yourself

1. Why is a Kubernetes Secret not encrypted by default? Answer: it is base64-encoded, which anyone can decode, so a reader of the object or of etcd can see the value.
2. When would you choose Vault over a cloud secret manager? Answer: when you need dynamic database or cloud credentials, several clouds, or encryption as a service.

Key takeaways

• Cloud managers suit single-cloud teams with mostly static secrets.
• Vault suits dynamic credentials and multi-cloud setups.
• Kubernetes Secrets need etcd encryption or an external source of truth.
• Next, envelope encryption explains how large data gets encrypted with a key service.

Further learning

Vault's documentation covers dynamic secrets, policies and transit encryption.

HashiCorp Vault documentationVault product and reference documentation covering key concepts, guides for common tasks, and best practices.Vault product documentation | Vault | HashiCorp Developer

Armon Dadgar's introduction to Vault is still the clearest explanation of why centralized, audited, rotatable secrets beat secret sprawl.