It is 2026. There are .env files committed to private repositories right now. There are passwords in Kubernetes Secret objects encoded as base64, which is not encryption, and someone on that team thinks it is. There are production credentials in a shared Bitwarden folder with twelve people’s access that nobody has audited since the last two people left.

Secrets management is a solved problem in the sense that we know what good looks like. It’s an unsolved problem in the sense that most teams aren’t doing it.

This post is a tour of the current landscape, what actually works, and what the traps are.

The options #

HashiCorp Vault is the industry standard and earns that title. Dynamic secrets, fine-grained policies, audit logging, multiple auth backends, a mature operator ecosystem. It’s also operationally heavy. Running Vault in HA requires real thought about storage backends, unsealing, and cluster membership. The free tier covers most use cases but the BSL licence change in 2023 left some teams uneasy. OpenBao is the community fork if that matters to you.

External Secrets Operator (ESO) is the Kubernetes-native answer. It doesn’t store secrets. It syncs them from wherever you already have them (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, Vault, 1Password, and a dozen others) into Kubernetes Secret objects. If you’re on Kubernetes and already using a cloud provider’s secret store, ESO is often the right choice: you get GitOps-friendly ExternalSecret manifests, automatic refresh, and you’re not adding another stateful thing to run.

Infisical is the newcomer that’s earned a serious look. Open source, self-hostable, with a clean UI, native Kubernetes operator, CLI injection (infisical run --), and a managed cloud tier. It bridges the gap between “too simple” (Bitwarden) and “too much” (Vault) for teams that aren’t operating at Vault scale but want more than environment variables in a file.

Cloud-native stores (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) are the right answer if you’re already committed to one cloud and don’t need portability. Managed, cheap at low scale, IAM-integrated. The friction comes when you’re multi-cloud or need to inject secrets into non-cloud workloads.

Sealed Secrets deserves a mention: encrypts Kubernetes secrets so you can commit them to Git. Solves the “we use GitOps but secrets can’t go in the repo” problem specifically. Narrow tool, does its job well.

The pattern that actually works #

The principle is the same regardless of tooling: secrets live in one place, everything else references them.

That means:

  • No copying secrets between systems
  • No secrets in environment files that get deployed with the app
  • No secrets in CI/CD variables that someone set three years ago and nobody knows what they’re for anymore
  • Applications get secrets injected at runtime, not baked in at build time

In Kubernetes this looks like ESO pulling from your secret store into short-lived Secret objects, with rotation handled by the store. In Compose environments it looks like infisical run -- docker compose up -d. In CI/CD it looks like OIDC-based access to your cloud secret store rather than long-lived tokens stored as pipeline variables.

The shape is: identity-based access, not credential-based access. Your workload authenticates as itself (service account, instance profile, OIDC token) and gets secrets it’s allowed to have. No pre-shared passwords to rotate. No human in the path.

The traps #

Base64 is not encryption. Kubernetes Secret objects are base64-encoded by default, which is encoding, not security. If someone can read Secrets in your cluster, they can read your secrets. etcd encryption at rest helps, but the bigger issue is RBAC: most clusters are too permissive about who can list and get secrets across namespaces. Audit this before you deploy anything sensitive.

Secret sprawl happens faster than you think. You start with one secret store, then someone needs a quick fix and puts a value in a CI variable. Then a contractor needs access and gets a personal API key. Then the key rotation script creates a new key but the old one isn’t deleted. Six months later you have secrets in four places and a rotation process that covers two of them. Centralisation is not a one-time migration, it’s a discipline.

Rotation is the hard part. Storing secrets centrally is relatively easy. Rotating them without downtime is where most systems fall apart. Dynamic secrets (Vault’s killer feature) sidestep this by issuing short-lived credentials on demand. No rotation needed because the credential expires on its own. If you’re not using dynamic secrets, you need a rotation strategy from day one, not after the first breach.

The Vault complexity trap. Teams adopt Vault because it’s the right tool, then spend six months configuring auth backends, policies, and namespaces before they’ve protected a single production secret. If you’re a team of ten, Vault’s operational weight might not be worth it yet. Infisical or a cloud-native store with ESO will get you 80% of the benefit at 20% of the overhead. Reach for Vault when you need what Vault specifically provides: dynamic secrets, PKI, SSH signing, complex policy hierarchies.

OIDC in CI/CD is still underused. Most teams are still passing long-lived tokens into GitHub Actions or GitLab CI as repository secrets. OIDC-based access (your pipeline authenticates with a short-lived token issued by the CI provider, which AWS/GCP/Azure or Vault trusts) eliminates the long-lived credential entirely. The setup takes an afternoon. The payoff is permanent.

Where things actually stand #

The tooling is good. ESO is mature and well-maintained. Infisical has momentum. Vault is stable. The cloud stores are reliable. There’s no excuse for the state most teams are in on the tooling side.

The gap is cultural and operational. Secrets management doesn’t feel like a feature, so it doesn’t get prioritised. The .env file works until it doesn’t. The Kubernetes secret with base64 encoding feels fine until there’s an incident. The CI variable from 2022 keeps working so nobody touches it.

The actual work is treating secrets management as infrastructure — something that gets designed, documented, reviewed, and rotated on a schedule. Not a one-time setup, and not something you figure out during a post-mortem.

The tooling is the easy part. The discipline is what’s missing.