external-secrets

What it is

External Secrets Operator (ESO) is a Kubernetes controller that syncs secrets from external secret management systems — Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, and a dozen others — into native Kubernetes Secret objects. It replaces the pattern of hand-copying credentials into kubectl create secret or committing sealed secrets to git. You define an ExternalSecret custom resource pointing at a path in your backend, and ESO keeps the cluster-side Secret in sync on a schedule, handling rotation without a redeploy.

It's provisioning-layer plumbing: it doesn't store secrets itself, it brokers between your existing secret store and the Kubernetes API.

Who builds it and why

Originally started by GoDaddy engineers frustrated with maintaining bespoke secret-sync scripts, the project has since become a genuinely multi-vendor effort — 688 contributors is a large number for a CNCF Sandbox project and reflects heavy involvement from cloud providers and platform teams who each want their own backend supported well. It sits in CNCF Sandbox, meaning it has community traction but hasn't yet gone through the incubation maturity bar (documented governance, security audits, broad production testimonials at scale).

The motivation is straightforward: every org running Kubernetes eventually hits the "how do secrets get from Vault into a Pod" problem, and ESO is the de facto answer most teams converge on instead of building it in-house.

Production readiness signal

Activity is strong and current — a commit as recent as July 2026 alongside 6.7k GitHub stars indicates active, ongoing maintenance rather than a stalled sandbox project. The contributor count (688) suggests broad usage across enough companies that people are upstreaming their own provider integrations and bug fixes, not just one vendor carrying the project.

That said, CNCF Sandbox status is a real signal, not a formality: it means the project hasn't yet demonstrated the governance maturity, security review cadence, or long-term backing guarantees that Incubation/Graduated projects have. Check the release notes on helm-chart-2.7.0 for breaking changes before upgrading — provider-specific behavior (especially around Vault auth methods and GCP workload identity) has historically been a source of upgrade friction.

Who should use this

• Teams already running Vault, AWS/GCP/Azure secret managers, and want Kubernetes to consume from them without duplicating secret storage.
• Platforms enforcing GitOps where secrets can't live in git — ESO lets you commit the ExternalSecret manifest (which references a path, not a value) instead of the secret itself.
• Multi-cloud or multi-provider shops that need one consistent CRD-based interface instead of provider-specific sidecars or init containers.

Who should NOT use this

• Small teams with a single cloud provider already using that provider's native CSI secret store driver (e.g., AWS Secrets and Configuration Provider) — ESO adds a control loop and CRD surface you may not need.
• Anyone expecting audit-grade compliance guarantees out of the box — Sandbox status means you're responsible for validating security posture yourself; there's no CNCF-backed audit yet.
• Teams wanting secrets never to touch the Kubernetes API/etcd at all — ESO still materializes a native Secret object, so if your threat model excludes etcd-stored secrets entirely, you want a runtime-injection tool (e.g., Vault Agent sidecar) instead.
• Air-gapped or offline environments without reliable connectivity back to the secret backend — sync failures degrade gracefully but you're still dependent on that external call succeeding.

Alternatives

• Vault Agent Injector – injects secrets directly into pod filesystems at runtime instead of materializing Kubernetes Secrets, better fit if you want zero-etcd-persistence.
• AWS/GCP Secrets Store CSI Driver – native, provider-specific CSI drivers that mount secrets as volumes without a custom controller; simpler if you're single-cloud.
• SOPS + Sealed Secrets – git-native encrypted secret storage, a different philosophy (encrypt-in-git vs. sync-from-external-store) worth considering if you don't want to run an external secret manager at all.

Pricing

Fully open source, Apache-2.0 licensed. No paid tier, no enterprise edition. You pay only for the underlying secret backend (Vault, AWS Secrets Manager, etc.) you connect it to.