Platform Monkey ctx

External Secrets Operator: Seven Projects, One CRD, and the Burnout Test

2018–present · · By

GoDaddy's kubernetes-external-secrets was the popular kid; six rivals merged into a from-scratch Go rewrite that became the de facto way secrets enter Kubernetes.

Sources

GoDaddy's kubernetes-external-secrets was the popular kid; six rivals merged into a from-scratch Go rewrite that became the de facto way secrets enter Kubernetes.

Every platform team eventually writes the same controller: one that reads a reference from Git, fetches the actual value from AWS Secrets Manager or Vault, and materializes a native Kubernetes Secret. The reason that controller has a name everyone agrees on is a story about consolidation — seven competing projects, one deliberate rewrite, and a governance stress test that arrived exactly when the project became too important to fail. This is the tale of External Secrets Operator (ESO), and of the GoDaddy project that preceded — and outlived itself into — it.

The Origin: GoDaddy's Node.js Controller and the Land Rush It Triggered

The story starts at GoDaddy in December 2018. On December 10, 2018, Jacopo Daeli pushed the initial commit to kubernetes-external-secrets (KES). It was a Node.js controller — a detail that matters enormously later. KES extended Kubernetes with an ExternalSecret CRD whose controller talked to cloud secret managers and wrote native Secrets. GoDaddy published the design motivation on its engineering blog in April 2019, and the project hit the front of Hacker News the same day with 69 points.

KES was the right idea at the right moment. Secrets in Git were anathema; secrets in clusters were already there and unrotated. By early 2021 it counted roughly 1,700 stars and supported Alibaba Cloud, Azure Key Vault, GCP, IBM Cloud, AWS Secrets Manager, AWS SSM, and HashiCorp Vault. It was, in the words of the community that would eventually replace it, "the most popular kid in school."

And that popularity created the problem. A problem this broadly felt produces a land rush: by 2020 there were at least seven projects doing the same thing — ContainerSolutions/externalsecret-operator (Go, by Riccardo M. Cefala, born from a client engagement), itscontained/secret-manager (Kellin McAvoy and Nicholas St. Germain), mumoshu/aws-secret-operator (Yusuke Kuoka), cmattoon/aws-ssm, tuenti/secrets-manager, kubernetes-sigs/k8s-gsm-tools, and GoDaddy's KES. The very first consolidation signal was prosaic: KES issue #47, "Consider merging with aws-secret-operator", filed in April 2019 by max-lobur. The merge did not happen for another eighteen months — but the idea that this problem needed one project, not seven, was now on the record.

The technical case for consolidation was written by Moritz Johner in issue #477, "Standardize CRD Spec" (September 2020): a shared CRD specification, maintained in a dedicated crd-spec repository (created November 19, 2020), so that the control plane and the ecosystem of tools around it could stabilize independently of any single implementation. The strategic case was simpler: KES was JavaScript, and the Kubernetes operator ecosystem had standardized on Go — first-class client-go SDKs, kubebuilder scaffolding, and the controller-runtime patterns every contributor already knew.

The Timeline: Consolidation, Rewrite, Crisis, Recovery

Crisis Points and Architectural Pivots

The consolidation itself was the first crisis, and it was engineered rather than survived. Seven projects with overlapping CRDs is a fragmentation tax on the entire ecosystem: every blog post, every helm chart, every platform template had to pick a winner. The external-secrets community solved it with process — a negotiated common CRD spec first, implementation second — and then did the counterintuitive thing: rather than adopting the codebase of the largest candidate, they rewrote from scratch and "just copied and adapted code that made sense." The CRD was the point of agreement; the code was disposable. That decision is why ESO's API feels designed rather than accreted.

The SecretStore split (v0.5.0) was the architectural pivot that made ESO deployable at scale. The original single-resource design coupled where a secret lives with how to authenticate to that backend. v0.5.0 pulled authentication into namespaced SecretStore and cluster-wide ClusterSecretStore resources, letting platform teams own store definitions once while application teams emitted only ExternalSecret references. It forced a breaking change on dataFrom to get there. This is the split that turns ESO from a syncing tool into platform plumbing — the reason an internal developer platform can offer "secrets" as a service with one ClusterSecretStore per backend.

apiVersion: external-secrets.io/v1
kind: SecretStore          # namespaced: how to authenticate
metadata:
  name: vault-prod
spec:
  provider:
    vault:
      server: "https://vault.example.com"
      path: "secret"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "eso"

---
apiVersion: external-secrets.io/v1
kind: ExternalSecret      # what to fetch, by reference
metadata:
  name: payments-api-key
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-prod
    kind: SecretStore
  target:
    name: payments-api-key
  data:
    - secretKey: api-key
      remoteRef:
        key: payments/prod
        property: api-key

The 2025 pause was the real stress test — and the response pattern is the lesson. ESO hit the classic mid-life open-source wall: massive deployment (the provider matrix spans AWS, Azure, GCP, Vault, 1Password, Akeyless, Doppler, Infisical, Keeper, Conjur, Fortanix, and ~thirty more), but a maintainer bench of five doing the work in their spare time or on employer goodwill. The maintainers' move was honest and public: we pause releases until more maintainers step up. Compare the alternatives — quiet abandonment, or a rug-pull license change. The pause was governance working as designed: pressure routed to the community that benefits from the project rather than absorbed silently by five people. External Secrets Inc., which had launched ten months earlier, publicly committed upstream investment in its Turning Point post — a commercial entity built on the project buying insurance on its own foundation. Three months later, v1.0.0 shipped.

The v2.0.0 provider purge is the quiet signal of maturity. Removing Alibaba and Device42 stores for lack of maintainers is the unglamorous half of governance: an honest shrink. Projects that only ever grow acquire surface area nobody supports; ESO demonstrated it can cut, breaking API be damned — with a major version to say so plainly.

Community Engine: Who Actually Built It

The founding DNA is visible in the first hundred commits: Moritz Johner (moolen, at Form3Tech) drove the CRD standardization and the early implementation; Lucas Severo Alves (knelasevero, then at Container Solutions) wrote the community's founding narrative and evangelized it; Jonatas Baldin built out the provider interface; Flydiverny and silasbw carried GoDaddy's KES through its final maintained years and into the new org. Container Solutions contributed engineering time and e2e infrastructure during the rewrite. Today's MAINTAINERS.md lists five maintainers — knelasevero (no affiliation), gusfcarvalho (External Secrets Inc.), moolen (Form3Tech), IdanAdar (IBM), and Skarlso (Kubermatic) — with the technical-lead and chief-architect seats empty.

The corporate layer is unusually legible for a CNCF sandbox project. GoDaddy incubated the original. Container Solutions brokered the merger. IBM and Form3Tech employ maintainers. External Secrets Inc. runs the commercial distribution — "enterprise drop-in replacement delivering stability, SLAs, and advanced features" is how its own blog puts it — and, per the same post, positions the open core as "a vendor-neutral ground for contribution." The project's documentation sits at external-secrets.io, and adoption shows up everywhere secrets need to cross a boundary: our own GitOps secrets guide treats ESO as the default pull-based option, and the org has grown side repos — kes-to-eso (migration), bitwarden-sdk-server (Rust SDK wrapper), reloader (secret-triggered rollouts) — that make it a small ecosystem rather than a single controller.

The numbers as of this writing: roughly 6,900 stars, 1,445 forks, 100+ contributors, forty-odd providers, Apache-2.0, CNCF Sandbox since August 2022. For perspective on the consolidation's payoff: KES — the project that once owned this entire space — is archived with 2,579 stars. Its successor carries nearly triple the adoption and none of the language debt.

Current Trajectory: The Verdict

ESO is the rare consolidation story that actually consolidated. It ate seven codebases' worth of demand, standardized one CRD, and became the default answer to "how do secrets get into Kubernetes without living in Git?" — so thoroughly that the question is now boring, which is the highest compliment infrastructure can earn. The v2.x cadence (v2.0.0 in February 2026 through v2.11.0 in September 2026) suggests the 2025 pause was a course correction, not a death spiral.

The open questions are the honest ones. The maintainer bench is still thin — five names, two empty leadership seats, one company carrying the commercial weight. CNCF Sandbox status since 2022 means ESO has never been pushed through incubation, which is either refreshing indifference to prestige or unfinished governance, depending on your reading. And External Secrets Inc. is simultaneously the project's insurer and its most conflicted stakeholder: the same entity publishing "we will step up and fill any gaps" is the one selling the paid alternative to waiting for the gaps to be filled. That arrangement works — right up until the day the upstream and the enterprise product need different things. The Flux and Weaveworks arc shows how that story can end; ESO's own history shows the community absorbing the risk instead. Watch the release cadence and the MAINTAINERS file. Those two artifacts will tell you ESO's future before any blog post does.

Platform Monkey's verdict: adopt with eyes open. ESO is the sensible default for pull-based secret sync — a mature v1 API, a provider for nearly everything, and governance that has already survived its worst day in public. Pin your store definitions to external-secrets.io/v1, run the controller with tight RBAC on its store resources, and budget attention for the provider matrix: the stores ESO removed in v2.0.0 are the reminder that every provider you enable is a dependency someone has to maintain. If your platform offers secrets as a service, this is the plumbing under it — and if you depend on it in production, the 2025 pause is your standing invitation to contribute back.