Kubernetes secret management in 2026: External Secrets, SOPS, or Vault?

The Decision Most Platforms Got Wrong in 2023

In 2022 and 2023, a lot of platform teams adopted Sealed Secrets — the Bitnami project that encrypts secrets client-side with a cluster-held key, then commits the encrypted sealed secret to Git. It is simple, it is GitOps-native, it was the reasonable choice at the time.

By 2026, for any platform running more than two production clusters, Sealed Secrets has become the wrong answer. The reasons are architectural: Sealed Secrets are bound to a specific cluster’s sealing key, so you cannot easily promote the same sealed secret across clusters; rotation is manual; there is no audit trail for secret access; and the threat model (“only a cluster admin can decrypt”) is stronger than most teams need but weaker than regulated environments require.

Three tools now dominate the production Kubernetes secret management landscape, and each is better than Sealed Secrets for specific workloads: External Secrets Operator (ESO), SOPS with Mozilla age, and Vault Agent injector. This is the 2026 decision framework for picking between them — and, crucially, for using more than one in the same platform without creating an operator zoo.

Start With the Threat Model

Every secret management decision starts with the same four questions:

1. Where does the secret come from (the “source of truth”)?
2. Who is allowed to read it, and under what conditions?
3. How is it rotated?
4. What audit trail does a secret access produce?

Different tools answer these differently, and the right tool is whichever one matches your answers most naturally. Forcing the same tool onto every use case — one-size-fits-all — is the source of most operator sprawl and most rotation incidents.

External Secrets Operator: The 2026 Default for Most Platforms

External Secrets Operator (ESO) is a Kubernetes controller that fetches secrets from an external secret store (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler, Infisical, and so on) and materializes them as Kubernetes Secret objects. You declare an ExternalSecret resource in Git; ESO reconciles it by pulling the current value from the source of truth.

The 2026 profile:

• CNCF Incubating project, maintained by an active community, ESO v1 (GA in 2024) stable and widely adopted
• Supports 30+ provider backends including all major cloud secret managers, Vault, Infisical, Akeyless, and several password managers
• Rotation is source-of-truth driven: update the secret in AWS Secrets Manager, ESO re-fetches on the configured refresh interval, the Kubernetes Secret is updated, and downstream deployments optionally restart
• Native ClusterSecretStore concept supports multi-tenant clusters with per-namespace source-of-truth access
• ESO itself never stores secrets — only manages references

When ESO is the right choice:

• You already have AWS Secrets Manager, GCP Secret Manager, or another cloud-native secret store and want Kubernetes workloads to consume those secrets with IAM-based access control
• You want to decouple the secret lifecycle from the cluster lifecycle — restoring a cluster from scratch does not require re-sealing every secret
• You want a unified secret store across Kubernetes and non-Kubernetes workloads (Lambda, ECS, bare VMs)
• You want clean per-namespace isolation with cloud IAM roles, not cluster-internal RBAC

When ESO is the wrong choice:

• You do not want to depend on a running cloud control plane for pod startup. If AWS Secrets Manager has an outage, new pods fail to start. (ESO caches secrets in etcd, so existing pods keep running; new pods scheduled during the outage still fetch from the cached secret, but a cluster rebuild during an outage is painful.)
• You need file-system-level secret injection at pod startup with dynamic per-pod secrets — use Vault Agent instead
• You want to keep the secret source of truth in Git itself — use SOPS

SOPS + age: The Right Answer for Small Platforms and Disaster Recovery

Mozilla SOPS — with the age encryption backend — encrypts secret values in a YAML or JSON file using public-key cryptography. The encrypted file is committed to Git. A Flux, Argo CD, or Kustomize-with-ksops plugin decrypts on apply using a private key held in the cluster.

The 2026 profile:

• Mature, simple, no external dependency at pod-start time
• age (by Filippo Valsorda) is now the preferred SOPS backend over PGP for new deployments — simpler keys, better performance, smaller footprint
• Flux has first-party SOPS integration; Argo CD uses the argocd-vault-plugin or Kustomize ksops
• The entire secret history lives in Git — exactly as auditable as your infrastructure code
• Key management becomes the new problem: rotating the age key is a cluster-wide operation

When SOPS is the right choice:

• Small platforms (1–3 clusters) where operational simplicity outweighs multi-tenant needs
• GitOps-native teams where “infra is code” is non-negotiable and a cloud secret manager feels like an external dependency
• Disaster recovery / air-gapped environments where you cannot rely on a cloud secret manager being reachable
• Configuration-like secrets that rarely rotate and where versioning in Git is a feature

When SOPS is the wrong choice:

• Secrets that rotate frequently (daily or on-demand). Every rotation is a Git commit.
• Multi-cluster promotion pipelines. The same encrypted file cannot be decrypted in two clusters with different keys without multi-recipient encryption, and multi-recipient adds operational complexity.
• Teams where developers should not see the encrypted ciphertext. Git history is visible to everyone with repo access.
• Secrets that need short-lived / dynamic issuance (database credentials issued per workload, for example).

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

Vault Agent Injector: When You Need Dynamic Secrets

HashiCorp Vault with the Vault Agent sidecar injector is the most sophisticated and most operationally expensive option in this comparison. It earns its keep in exactly two scenarios: you need dynamic secrets (short-lived credentials issued per-workload, not static ones stored somewhere), or you have a regulatory obligation that requires Vault specifically.

The 2026 profile:

• Vault (now both self-hosted and HCP Vault, with HCP Vault Dedicated the 2026 managed offering) remains the gold standard for dynamic secrets — short-lived database credentials, cloud IAM credentials via STS, PKI certificates
• The Vault Agent injector mutates pods to add a sidecar or init-container that fetches secrets from Vault at pod startup and writes them to a shared volume
• Kubernetes auth method uses pod service account tokens for identity — no static Vault tokens in the cluster
• Templated secret files — the agent renders secrets from Vault into config files at runtime, with automatic rotation on TTL expiry
• Strong audit trail; every secret access is logged in Vault with pod identity attached

When Vault Agent is the right choice:

• You need database credentials that are issued per-pod and revoked when the pod dies. Vault’s database secret engine issues short-lived credentials on demand; the pod uses them; they expire.
• You need short-lived cloud IAM credentials for workloads that cannot use IRSA / Workload Identity (usually a legacy or cross-cloud concern)
• Regulated environments (FFIEC, PCI, HIPAA with strict interpretations) where “Vault” is specifically a control
• You already run Vault for non-Kubernetes workloads and want consistency

When Vault Agent is the wrong choice:

• You do not actually need dynamic secrets. Static secrets injected at pod start are the 80% case, and ESO is simpler.
• Small teams without Vault operational experience. Vault is not a casual dependency; unseal keys, replication, disaster recovery, and version upgrades are real work.
• Pure cloud-native platforms on a single cloud where IRSA (AWS) or Workload Identity (GCP) already solves the cloud-IAM problem.

The Combined Architecture for Multi-Cluster Platforms

In practice, a mature 2026 platform does not pick one tool — it uses two, sometimes three, with a clear allocation of responsibilities.

A common working combination:

• ESO for application secrets. API keys, third-party integration credentials, OAuth client secrets — sourced from AWS Secrets Manager or GCP Secret Manager. Namespaces get per-team access via IAM roles for service accounts.
• SOPS for GitOps-managed configuration secrets. TLS certificates, SSH keys used by the platform itself, the ESO and Vault bootstrap credentials. Lives in Git for disaster recovery and for first-boot ordering.
• Vault Agent injector for dynamic database credentials. Only on the subset of workloads that need per-pod database credentials. Typically the high-value tier — billing, PII stores, regulated data planes.

This architecture handles the “operator zoo” concern because the division of labor is explicit. SOPS has a narrow role (disaster-recovery-friendly bootstrap secrets). ESO handles the bulk of application secrets with cloud IAM integration. Vault handles the dynamic-credential tier where it earns its complexity.

Rotation: The Part Everyone Underestimates

Rotation is what separates secrets theater from secrets operations. A 2026 production platform has three categories of rotation policy:

• Manual rotation (monthly or quarterly) — Low-risk API keys, vendor integration credentials. SOPS and ESO both handle this via a Git commit or a secret-store update.
• Scheduled automated rotation (daily or weekly) — High-risk service-to-service credentials. AWS Secrets Manager rotation + ESO is the clean pattern.
• On-demand short-lived issuance (minutes) — Database credentials, cloud IAM credentials. Vault dynamic secrets is the only clean option at this tier.

Each tier has a different trade-off between operational simplicity and credential exposure window. Regulated environments typically mandate the third tier for database access. Most startups can live at tier one for most secrets and tier two for service-to-service credentials.

The Audit Trail

When an auditor asks “who accessed the production database credentials last quarter?”, the answer depends entirely on the tool:

• SOPS — Git commit history. You see who committed, not who decrypted at runtime.
• ESO — The underlying cloud secret manager’s audit trail (CloudTrail for AWS Secrets Manager, Cloud Audit Logs for GCP Secret Manager). Attribution is by IAM role/service account, which maps to namespace.
• Vault — Vault audit log, with pod-level identity attribution via the Kubernetes auth method.

For regulated environments, Vault and ESO produce the right audit trail; SOPS does not. Factor this into the decision early — retrofitting audit trail after a SOC 2 audit fails is expensive.

Migrating Off Sealed Secrets

If you are still on Sealed Secrets and considering this migration, the path is:

1. Inventory. List every SealedSecret in every cluster. Categorize into static application secrets, static platform secrets, and anything that should be dynamic.
2. Pick the destination per category. Most go to ESO with a cloud secret manager. A small number of bootstrap secrets go to SOPS. Dynamic candidates go to Vault if justified.
3. Bootstrap ESO/Vault in each cluster. This is a one-time effort; use your existing GitOps pipeline.
4. Migrate one namespace at a time. Stand up the new secret in the new store; apply a side-by-side ExternalSecret or VaultStaticSecret; cut over the workload; delete the SealedSecret.
5. Document the rotation policy. This is the artifact the migration produces — a secrets-management-policy document with one row per secret category and the rotation cadence.

Expect two to six weeks for a platform with 3–10 clusters. The migration is not urgent; the architectural cleanup is.

How IAN Helps

IAN audits your Kubernetes clusters for secret-management posture. It flags Sealed Secrets remnants, plaintext Secret resources that should be backed by ESO, SOPS-encrypted files with expired keys, Vault Agent injection annotations on deployments with no matching policy, and rotation-cadence violations against your declared policy.

When IAN finds a gap — a stale sealed secret, a missing ExternalSecret for a known application secret, a Vault-injected pod without audit log coverage — it opens a pull request with the fix and wires up the corresponding source-of-truth reference. Combined with IAN’s continuous audit, the secret-management posture stays in line with policy without manual review cycles.

The Decision Tree, Shortened

If you remember nothing else:

• Static application secrets, already using AWS/GCP/Azure? External Secrets Operator.
• GitOps-native small platform, one or two clusters? SOPS with age.
• Dynamic database or cloud credentials, regulated environment? Vault Agent injector.
• Still on Sealed Secrets and above two clusters? Plan the migration.

The right answer is almost never “one tool for everything.” The right answer is a clear allocation of responsibilities across ESO, SOPS, and Vault — with each tool doing the specific job it is best at.

Get a free infrastructure audit → | See pricing →