Every Kubernetes cluster eventually hits the same wall: the built-in Secret object just encodes values in base64, and base64 is not encryption. Once a team notices that anyone with read access to a namespace can decode a database password in five seconds, the search for a real secrets strategy begins. Three names come up in almost every one of those searches: External Secrets Operator, Bitnami Sealed Secrets, and HashiCorp Vault. As of September 26, 2026, each has shipped a fresh release in the last two weeks, and the gap between them is bigger than most teams realize.
External Secrets Operator (ESO) just hit v2.11.0 on September 18, 2026. Sealed Secrets shipped v0.40.0 on September 10, migrating fully under the Bitnami org after Broadcom’s VMware restructuring. HashiCorp Vault pushed v2.1.1 on September 16, seven months after Vault crossed its first major version jump from the 1.x line to Vault 2.0 in April 2026. None of these are minor footnotes. This comparison walks through what each tool actually does, what it costs, where the vulnerabilities have shown up, and which one fits which team, using version numbers, GitHub data, CVE records, and cloud pricing pulled directly from official sources this month.
Why the Native Kubernetes Secret Object Isn’t Enough
A stock Kubernetes Secret stores its value as base64 text inside etcd. Base64 is an encoding, not encryption, and decoding it takes one command: echo $VALUE | base64 -d. Unless a cluster operator has explicitly turned on encryption at rest for the API server, that value sits in etcd in a form anyone with etcd access, a backup snapshot, or the right RBAC permissions can read in plain text. Kubernetes documentation itself is blunt about this limitation, describing Secrets as “not particularly secure” without additional encryption configuration.
The second problem is distribution. Teams running GitOps pipelines want every manifest, including the ones that reference credentials, to live in version control. Committing a plaintext Secret object to a public or even a shared private repository is an incident waiting to happen. That single requirement, keep the source of truth in Git without leaking secret material, is what split the ecosystem into three distinct approaches instead of one obvious winner.
External Secrets Operator solves it by keeping the actual value out of Git entirely and pulling it from an external system at runtime. Sealed Secrets solves it by encrypting the value so the ciphertext is safe to commit. HashiCorp Vault solves it by replacing the whole model with a centralized, dynamic secrets engine that issues short-lived credentials instead of static ones. Each answer has real tradeoffs, and the right one depends less on which tool is “best” and more on what a given platform team is already running.
External Secrets Operator: What It Is and How It Works
External Secrets Operator is a Kubernetes controller that reads a value from an external secret store and materializes it as a native Secret object inside the cluster. It joined the CNCF Sandbox on July 26, 2022, and by September 2026 its provider list has grown to roughly 41 backends according to the project’s own documentation tree, covering AWS Secrets Manager, AWS Systems Manager Parameter Store, Azure Key Vault, Google Cloud Secret Manager, IBM Cloud Secrets Manager, HashiCorp Vault, OpenBao, CyberArk Conjur, Akeyless, 1Password, Doppler, Bitwarden, and Pulumi ESC among others.
The workflow is declarative. An engineer defines an ExternalSecret custom resource that points at a key or path in the backend store. The operator’s controller authenticates to that store, fetches the current value on its refresh interval, and writes (or updates) a standard Kubernetes Secret that any pod can mount or consume exactly like it always has. Nothing about the consuming application changes. That’s the core appeal: teams get centralized secret storage without rewriting how workloads read credentials.
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: db-credentials
namespace: production
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secretsmanager
kind: ClusterSecretStore
target:
name: db-credentials
creationPolicy: Owner
data:
- secretKey: password
remoteRef:
key: prod/db/passwordThe Git repository only ever contains that manifest: a pointer, a refresh interval, and an authentication reference. The password itself never touches version control. That property is why ESO has become what several Kubernetes security guides now call the de facto standard for GitOps-safe secret synchronization, and why Red Hat ships it as a supported Operator on OpenShift rather than building a competing tool from scratch.
Sealed Secrets: What It Is and How It Works
Sealed Secrets takes the opposite approach. Instead of keeping the value outside Git, it encrypts the value so the encrypted form is safe to commit anywhere, including a public repository. A command-line tool called kubeseal takes a normal Secret manifest and an RSA public key served by the in-cluster controller, then outputs a SealedSecret custom resource containing ciphertext. That ciphertext is what gets committed to Git.
kubectl create secret generic db-credentials
--dry-run=client
--from-literal=password=mysecretvalue
-o yaml | kubeseal
--controller-name=sealed-secrets
--controller-namespace=kube-system
--format yaml > db-credentials-sealed.yamlOnce applied to the cluster, the Sealed Secrets controller uses its private key, which never leaves the cluster, to decrypt the SealedSecret and create a plain Kubernetes Secret behind the scenes. This is a genuinely simple model with a single moving part, no external service dependency, and no network calls at deploy time. It’s why Sealed Secrets, now maintained under the bitnami/sealed-secrets repository after Broadcom’s reorganization of the former Bitnami Labs projects, still carries the highest GitHub star count of the three core tools covered here: 9,291 stars as of this month, ahead of ESO’s 6,884.
The tradeoff is that the encrypted material still lives in Git, permanently, as long as that commit history exists. Rotating a value means resealing and re-committing rather than updating a value in an external vault. And the entire security model rests on one thing: the controller’s private key. Lose that key without a backup, and every sealed value in the repository becomes permanently unrecoverable. Leak that key, and every sealed value becomes readable.
HashiCorp Vault and OpenBao: What They Are and How They Work
HashiCorp Vault is a different category of tool entirely. Where ESO and Sealed Secrets are delivery mechanisms, Vault is a centralized secrets platform that can generate credentials on demand, lease them with a time-to-live, automatically revoke them, and log every access through a built-in audit device. IBM completed its $6.4 billion acquisition of HashiCorp on February 27, 2025, at $35 per share, and Vault now ships under IBM’s stewardship while keeping its open governance model for the Community Edition.
Vault reached version 2.0.0 on April 14, 2026, its first major version bump since the project launched years earlier, and the current release as of this month is v2.1.1, shipped September 16, 2026. In a Kubernetes context, three separate components handle integration: the Vault Agent Injector (a mutating webhook that adds a sidecar to fetch secrets at pod startup), the Vault CSI Provider (which mounts secrets as files through the Secrets Store CSI Driver), and the newer Vault Secrets Operator, or VSO, now at v1.6.0 as of September 24, 2026, which reconciles Vault data directly into native Kubernetes Secret objects in a pattern closer to how ESO behaves.
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
name: db-credentials
namespace: production
spec:
mount: kv
type: kv-v2
path: prod/db
destination:
name: db-credentials
create: true
refreshAfter: 1h
vaultAuthRef: static-authVault’s licensing shift matters here too. HashiCorp moved Vault’s source-available license to the Business Source License 1.1 in 2023, prompting the Linux Foundation to stand up OpenBao, a governance-independent fork that keeps the Mozilla Public License 2.0 and Vault-compatible APIs. OpenBao just shipped its own v2.7.0 on September 23, 2026, and has already accumulated 7,985 GitHub stars, ahead of both ESO and the standalone VSO repository. ESO supports OpenBao as a backend provider alongside Vault, so teams that want Vault’s operational model without HashiCorp’s commercial licensing terms increasingly route through OpenBao instead.
Full Specs Comparison
The table below lines up the current, verified specifications for all three tools plus their closely related components, pulled directly from each project’s GitHub repository and release notes this month.
| Attribute | External Secrets Operator | Bitnami Sealed Secrets | HashiCorp Vault / VSO |
|---|---|---|---|
| Latest version | v2.11.0 | v0.40.0 | Vault v2.1.1 / VSO v1.6.0 |
| Release date | Sep 18, 2026 | Sep 10, 2026 | Sep 16, 2026 / Sep 24, 2026 |
| GitHub stars | 6,884 | 9,291 | 36,302 (core Vault) |
| GitHub forks | 1,443 | 779 | 4,763 (core Vault) |
| License | Apache 2.0 | Apache 2.0 | BUSL 1.1 (Community) / commercial (Enterprise) |
| CNCF status | Sandbox (since Jul 26, 2022) | Not a CNCF project | Not a CNCF project |
| Secret material in Git | No, only a reference | Yes, as ciphertext | No |
| Backend providers supported | ~41 (AWS, Azure, GCP, Vault, OpenBao, 1Password, etc.) | None (self-contained) | Is the backend itself |
| Dynamic / leased credentials | Passthrough only, depends on backend | No | Yes, native lease and revoke |
| Requires external infrastructure | Yes, a supported backend store | No | Yes, the Vault cluster itself |
| Rotation on backend change | Automatic on refresh interval | Manual re-seal and re-commit | Automatic via lease TTL |
| Kubernetes integration model | Native Secret sync via CRD | Native Secret sync via CRD | Sidecar injector, CSI driver, or VSO CRD |
| Governance | CNCF Sandbox community | Broadcom / Bitnami org | IBM (Vault) / Linux Foundation (OpenBao fork) |
Security Model Deep Dive: Where Does the Secret Actually Live?
This is the question that decides which tool fits a given compliance posture, and the honest answer is more nuanced than “ESO is safe, Sealed Secrets is risky.” Every one of these tools, including ESO, still ends up creating a plain Kubernetes Secret object inside the cluster by default. That object still lives in etcd, still gets mounted into pod environments or filesystems, and still needs the cluster’s own encryption-at-rest and RBAC controls to stay protected once it exists. Choosing ESO over Sealed Secrets does not remove the need to lock down etcd access.
What differs is what a Git repository breach actually exposes. With Sealed Secrets, an attacker who gains read access to the repository sees ciphertext, and that ciphertext is useless without the Sealed Secrets controller’s private key, which lives only inside the target cluster. With ESO, an attacker who gains read access to the repository sees a reference: a key name, a path, and a store identifier. That’s arguably less useful to an attacker, but it also means ESO’s real security perimeter has simply moved to wherever the secret actually lives, and to whatever IAM role or auth method the operator uses to reach it. A misconfigured ESO service account with overly broad IAM permissions to AWS Secrets Manager is a bigger blast radius than a single sealed value ever was.
| Security property | ESO | Sealed Secrets | Vault |
|---|---|---|---|
| Single point of compromise | Backend auth credentials | Controller private key | Root token / unseal keys |
| Rotation without redeploy | Yes, on refresh interval | No | Yes, via lease expiry |
| Audit trail of access | Depends on backend | Kubernetes API audit log only | Built-in audit device |
| Blast radius if Git leaks | Low, only references exposed | Low, only ciphertext exposed | Not applicable, no secrets in Git |
| Blast radius if cluster is compromised | High, backend credentials reachable | High, private key reachable | High, but scoped by lease TTL |
Vault changes the calculation again by making every credential temporary. A database password issued through Vault’s dynamic secrets engine can carry a one-hour lease, after which Vault revokes it at the database level automatically. If that credential leaks, the exposure window is bounded by the lease, not by how quickly a human notices and rotates it manually. That’s a meaningfully different security posture than either ESO or Sealed Secrets can offer on their own, since both are ultimately delivery mechanisms for values that something else has to rotate.
Benchmarks: What the Available Data Actually Shows
Direct, apples-to-apples plan-and-apply style benchmarks for secrets tooling are harder to find than they are for something like Terraform, because these three products don’t do the same job in the same way. Rather than force a fabricated number, here’s what verifiable engineering data actually supports across three separate source types.
The first source is release cadence, which is a genuine proxy for engineering investment. GitHub’s own commit history shows External Secrets Operator shipping a new minor version roughly every three weeks throughout 2026, with v2.7.0 on June 26, v2.8.0 on July 18, v2.9.0 on August 7, v2.10.0 on August 28, and v2.11.0 on September 18. Sealed Secrets, by contrast, ships far less frequently, consistent with a stable, feature-complete tool rather than one still expanding its surface area. Vault’s core repository shows near-daily commit activity, reflecting its scope as a full secrets platform rather than a single-purpose operator.
The second source is the CNCF’s own project documentation, which describes ESO’s architecture as designed for horizontal scaling of the controller when secret counts climb into the thousands, using a configurable reconciliation interval to avoid hammering backend APIs. That’s a structural performance decision, not a marketing number, and it explains why most production ESO deployments tune the refreshInterval field upward (often to 1 hour or longer) rather than syncing every minute, specifically to stay under cloud provider API rate limits like AWS Secrets Manager’s per-account throttling.
The third source is HashiCorp’s own security advisory process, which is the most reliable signal available for how these systems behave under real operational stress: every disclosed CVE describes a specific failure mode in production use, covered in detail in the vulnerability section below. Between release cadence, documented architecture decisions, and the vulnerability record, the pattern that emerges is consistent: ESO trades sync latency for reduced blast radius, Sealed Secrets trades rotation convenience for architectural simplicity, and Vault trades operational overhead for the tightest lease-based control of the three.
Pricing Compared: The Tools Are Free, the Backends Aren’t
All three core projects, ESO, Sealed Secrets, and Vault’s Community Edition, are free and open source. The real cost shows up one layer down, in whatever backend store a team connects to, or in HashiCorp’s commercial tiers if a team needs enterprise support. Here is what each option actually charges as of September 2026, pulled from official pricing pages.
| Component | License / Tier | Cost |
|---|---|---|
| External Secrets Operator | Apache 2.0, self-hosted | $0 |
| Sealed Secrets | Apache 2.0, self-hosted | $0, no backend required |
| HashiCorp Vault Community Edition | BUSL 1.1, self-hosted | $0 |
| OpenBao | MPL 2.0, self-hosted | $0 |
| Vault Enterprise (self-managed) | Commercial | Custom quote, not publicly listed |
| HCP Vault Dedicated | Managed cloud service | Usage-based, quoted per deployment |
| AWS Secrets Manager (common ESO backend) | Pay-as-you-go | $0.40 per secret/month + $0.05 per 10,000 API calls |
| Azure Key Vault (common ESO backend) | Standard / Premium | $0.03 per 10,000 operations, no storage fee |
| Google Cloud Secret Manager (common ESO backend) | Pay-as-you-go | $0.06 per active version/month + $0.03 per 10,000 access ops (first 10,000/month free) |
The practical read: a team of any size running Sealed Secrets pays literally nothing beyond compute for the controller pod. A team running ESO against AWS Secrets Manager with, say, 200 secrets pays roughly $80 a month in storage fees alone before a single API call, which is real money at scale but trivial for most engineering budgets. Vault Community Edition is also free, but running it reliably in production, with proper unsealing, HA storage backend, and backup strategy, has a real operational cost in engineering time that none of these price sheets capture. HashiCorp deliberately doesn’t publish Enterprise or HCP Vault Dedicated pricing publicly, which itself is useful information: that tier is aimed at organizations for whom a sales conversation is the normal procurement path, not small teams comparison-shopping a price list.
GitHub Momentum, Governance, and Licensing
Star counts don’t measure code quality, but they do measure which direction the ecosystem is voting with its feet, and the trend lines here tell a real story. Sealed Secrets still leads on raw stars at 9,291, a legacy of being one of the earliest, simplest answers to the GitOps secrets problem back when the alternative was committing plaintext YAML. But its growth has flattened: this is now a mature, largely feature-complete project maintained under Broadcom’s Bitnami umbrella rather than a fast-moving one.
External Secrets Operator, at 6,884 stars, is newer and still accelerating, helped by its CNCF Sandbox status and the fact that its provider list keeps growing every quarter. OpenBao, born in 2023 purely as a reaction to Vault’s license change, has already reached 7,985 stars, more than either ESO or the standalone Vault Secrets Operator repository (602 stars), which says something about how much of the community wanted a genuinely open-source Vault-compatible option once HashiCorp moved to the Business Source License in 2023. Vault itself dwarfs all of them at 36,302 stars, a number that reflects a decade of being the default answer to “how do I manage secrets” long before Kubernetes-native tooling existed.
Governance is where the real divergence sits. ESO answers to a CNCF Sandbox technical steering committee, an open, multi-vendor model. Sealed Secrets answers to Broadcom’s Bitnami team, following VMware’s 2023 acquisition and Broadcom’s subsequent restructuring of Bitnami’s open-source portfolio, which has already led to changes in how some Bitnami container images are distributed. Vault Community Edition answers to HashiCorp, now a subsidiary of IBM since the $6.4 billion acquisition closed in February 2025, under a source-available license rather than an OSI-approved one. OpenBao answers to the Linux Foundation, explicitly positioned as the governance-independent alternative for teams uncomfortable with any single vendor controlling the roadmap.
Vulnerability Track Record: CVEs Disclosed in 2025 and 2026
A tool’s CVE history isn’t a mark of shame, active projects get security researchers’ attention precisely because people rely on them. What matters is severity, speed of the fix, and whether the vulnerability lines up with how the tool is actually deployed. Here’s the verified record across all three tools for the past 18 months.
| CVE | Affected component | Severity | Disclosed | Fixed in |
|---|---|---|---|---|
| CVE-2026-8715 | Vault Secrets Operator 1.3.0–1.4.1 | 9.6 Critical | Aug 13, 2026 | VSO 1.5.0 |
| HCSEC-2026-32 | Vault, templated policy paths | 6.8 Medium | Aug 24, 2026 | Patched release |
| CVE-2026-5807 | Vault root token/rekey DoS | Not rated in advisory | 2026 | Vault CE 2.0.0 |
| CVE-2025-6013 | Vault LDAP MFA bypass | 6.5 Moderate | 2025 | Patched release |
| CVE-2026-22822 | External Secrets Operator | 8.8 High | 2026 | Patched release |
| CVE-2026-42876 | External Secrets Operator | 4.9 Medium | May 12, 2026 | Patched release |
| CVE-2026-42875 | External Secrets Operator | Not rated | May 11, 2026 | Patched release |
| None found | Bitnami Sealed Secrets | — | — | No CVE on record for this window |
The most serious entry, CVE-2026-8715, is worth reading closely because it exposes exactly the risk this comparison keeps circling back to: a tenant with limited Kubernetes RBAC permissions could exploit a flaw in the Vault Secrets Operator’s AppRole configuration to read arbitrary files from the operator pod’s filesystem and exfiltrate their contents, a textbook privilege escalation path in a multi-tenant cluster. It was fixed within roughly six weeks in VSO 1.5.0. Sealed Secrets having no recorded CVE in this window isn’t necessarily proof of superior security engineering, it also reflects a smaller attack surface and a codebase with far fewer moving parts than either ESO’s 41-provider integration layer or Vault’s full secrets platform. Fewer features can mean fewer bugs, but it also means less scrutiny from security researchers who gravitate toward higher-impact targets.
Real-World Deployment Examples
These patterns show up repeatedly across production Kubernetes environments, based on how each tool’s design constraints map to actual team structures.
- A Red Hat OpenShift cluster running a supported ESO Operator. Red Hat began shipping External Secrets Operator as an officially supported Operator for OpenShift, letting DevSecOps teams pull credentials from CyberArk Conjur, Vault, or a major cloud provider’s secret store into a single, auditable source of truth rather than maintaining separate credential-injection scripts per environment.
- A five-person startup shipping its first production cluster. With no dedicated platform team and no existing cloud secret manager subscription, Sealed Secrets is the lowest-friction option: no external service to provision, no IAM policies to write, just a controller and a CLI, with the entire GitOps pipeline staying self-contained in one repository.
- A regulated fintech platform with database credentials that must rotate hourly. Static secrets, sealed or synced, can’t satisfy a compliance requirement for short-lived, auditable credentials. This is Vault’s dynamic secrets engine territory: it generates a fresh database user on demand, issues it with an hour-long lease, and revokes it automatically, producing an audit trail regulators can review.
- A platform team consolidating four separate clusters onto three different cloud providers. ESO’s roughly 41-backend provider list means the same
ExternalSecretpattern works whether the source is AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager, letting one GitOps template cover a genuinely multi-cloud footprint without per-cloud secret logic baked into application manifests. - A team migrating off HashiCorp’s Business Source License for procurement reasons. Organizations whose legal or procurement teams flagged BUSL 1.1 as incompatible with internal open-source policy increasingly route through OpenBao, since ESO and VSO-style tooling already treat it as a drop-in Vault-API-compatible backend.
- A CNCF-documented reference stack pairing OpenBao with CloudNativePG. The CNCF’s own September 16, 2026 blog post walks through running OpenBao on Kubernetes backed by CloudNativePG’s PostgreSQL operator, an entirely open-source, vendor-lock-in-free secrets stack that several platform teams have since cited as a template for their own OpenBao rollouts.
Use-Case Recommendations: Which Tool Fits Your Team
Choosing among these three comes down to team size, existing infrastructure, and compliance load more than raw feature counts. Here’s how the decision tends to play out in practice.
- Choose Sealed Secrets if: the team is small, has no existing cloud secret manager, and wants the entire secrets workflow to live inside one Git repository with zero external dependencies. It’s the fastest tool to adopt and the easiest to explain to a new hire in five minutes.
- Choose External Secrets Operator if: the organization already pays for AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager and wants a single, GitOps-friendly way to project those values into every cluster without duplicating secret management logic per environment.
- Choose HashiCorp Vault (or OpenBao) if: the workload needs dynamic, short-lived credentials, a full audit trail for compliance, or centralized secrets serving both Kubernetes and non-Kubernetes systems like VMs and CI pipelines from one platform.
- Choose OpenBao specifically over Vault if: legal, procurement, or open-source policy rules out the Business Source License, and the team is comfortable running a community-governed fork with a smaller (but growing) ecosystem than HashiCorp’s commercial offering.
- Choose ESO with Vault as the backend (rather than the Vault Agent Injector) if: the team wants the simplicity of native Kubernetes
Secretobjects for every workload, without adding sidecar containers or CSI mounts to every pod spec. - Avoid mixing all three across the same cluster unless there’s a deliberate migration in progress. Running Sealed Secrets, ESO, and Vault’s injector simultaneously in one namespace multiplies the number of places a misconfiguration can hide, and makes onboarding new engineers considerably harder.
Migration Guide: Moving Between These Tools
Migrations in this space are rarely all-or-nothing, and the safest path almost always runs both the old and new tool in parallel before cutting over.
Sealed Secrets to External Secrets Operator
Start by standing up a cloud secret store (AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager) and manually seeding it with the plaintext values currently locked inside existing SealedSecret resources. Decrypt each sealed value once, using kubeseal against the live controller if needed, then write it into the new backend. Install ESO, create a ClusterSecretStore pointing at that backend, and replace each SealedSecret manifest with an equivalent ExternalSecret referencing the same key path. Run both controllers side by side during the transition, since they don’t conflict, then remove the Sealed Secrets controller and delete the old SealedSecret manifests from Git once every workload has cut over.
External Secrets Operator or Sealed Secrets to Vault
This migration is heavier because Vault isn’t a drop-in replacement, it’s a different secrets model entirely. Deploy Vault (or OpenBao) with a highly available storage backend first, and get the unsealing and auto-unseal process production-ready before touching any application traffic. Migrate static secrets into Vault’s KV secrets engine as a first step, keeping the existing delivery mechanism (ESO with Vault as a backend, or the Vault Agent Injector) unchanged. Only after static secrets are stable should teams move toward Vault’s dynamic secrets engines for databases or cloud credentials, since that step requires each downstream system, a Postgres instance, an AWS account, to trust Vault as a credential issuer, which is its own change-management project.
# Point ESO at Vault instead of a cloud secret manager
apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
name: vault-backend
spec:
provider:
vault:
server: "https://vault.internal:8200"
path: "kv"
version: "v2"
auth:
kubernetes:
mountPath: "kubernetes"
role: "eso-role"This pattern, ESO reading from Vault rather than replacing it, is common in mature organizations: Vault stays the system of record and dynamic secrets engine, while ESO remains the thin, consistent Kubernetes delivery layer on top of it.
Pros and Cons of Each Platform
External Secrets Operator
- Pro: no secret material ever committed to Git, only references
- Pro: roughly 41 supported backends means one pattern works across multi-cloud clusters
- Pro: CNCF Sandbox governance, Apache 2.0, no licensing risk
- Con: requires an external secret store, adding a dependency and its own cost
- Con: has had more CVEs than Sealed Secrets in the past 18 months, including one 8.8-severity issue
- Con: sync latency depends on refresh interval, not instant like a native Secret
Sealed Secrets
- Pro: zero external dependencies, works entirely inside the cluster and Git
- Pro: simplest mental model of the three, easiest to onboard new engineers onto
- Pro: no CVEs on record for the past 18 months
- Con: rotation requires manually resealing and re-committing every changed value
- Con: encrypted material still lives permanently in Git history
- Con: entire security model depends on protecting one private key with no built-in HA story for that key
HashiCorp Vault (and OpenBao)
- Pro: only tool of the three offering true dynamic, leased, auto-revoked credentials
- Pro: built-in audit device gives a real compliance-grade access trail
- Pro: serves Kubernetes and non-Kubernetes systems from a single platform
- Con: Vault Community Edition is BUSL-licensed, a blocker for some procurement policies (OpenBao exists specifically to solve this)
- Con: highest operational overhead of the three, unsealing, HA storage, and backup all need real engineering investment
- Con: had the single most severe CVE among the three (9.6 Critical, VSO’s AppRole flaw)
Common Deployment Mistakes That Undo the Security Benefit
Picking the right tool doesn’t matter much if the deployment around it quietly recreates the exact problem the tool was supposed to solve. A few mistakes show up often enough to call out on their own.
The most common ESO mistake is granting the operator’s service account far broader IAM permissions than it needs, often a wildcard secretsmanager:GetSecretValue policy covering every secret in an AWS account instead of a scoped path. That turns a single compromised pod into a path to every credential the organization stores, which defeats the entire point of moving secrets out of Git. The fix is boring but effective: scope IAM policies to the exact secret paths a given ClusterSecretStore needs, and use separate stores per namespace or team rather than one global store with blanket access.
The most common Sealed Secrets mistake is treating the controller’s private key like any other cluster resource, with no backup and no rotation plan. Teams that lose the key during a cluster rebuild discover, usually during an incident, that every SealedSecret ever committed to Git is now permanently undecryptable, forcing a full re-seal of the entire secrets inventory under time pressure. Backing up that key to a separate, access-controlled location the moment the controller is first installed avoids the entire scenario.
The most common Vault mistake is skipping the operational hardening that a secrets platform of Vault’s scope actually requires: running a single Vault instance with no HA storage backend, no auto-unseal configuration, and a root token left active long after initial setup. Vault’s own hardening documentation explicitly warns against leaving the root token in day-to-day use, since it bypasses every policy the team has otherwise carefully written. CVE-2026-5807, the root-token and rekey denial-of-service issue fixed in Vault CE 2.0.0, is a direct reminder that the root-token workflow itself is sensitive enough to need careful handling, not casual reuse.
Verdict: Which One Should You Actually Use in 2026
There isn’t a single winner here, and treating this as a horse race misses the point of what each tool is for. For a small team with no existing secret manager subscription, Sealed Secrets remains the fastest path to a GitOps-safe cluster, and its clean CVE record over the past 18 months backs up its reputation for simplicity. For any team already paying for AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager, External Secrets Operator is close to a mandatory addition, its roughly 41-provider support and CNCF governance make it the connective layer that keeps a multi-cloud secrets strategy from turning into a pile of one-off scripts.
Vault earns its complexity when the requirement is dynamic, short-lived credentials or a compliance-grade audit trail spanning both Kubernetes and non-Kubernetes infrastructure, and its jump to a 2.0 major version in April 2026 signals HashiCorp is still investing heavily in the platform under IBM’s ownership. The one honest caveat is licensing: any organization uncomfortable with the Business Source License now has a legitimate, fast-growing alternative in OpenBao, which crossed 7,985 GitHub stars faster than either ESO or the standalone Vault Secrets Operator repository managed. The most common production pattern by far, and the one worth defaulting to absent a strong reason otherwise, is ESO synced to a cloud-native secret store for day-to-day application secrets, with Vault or OpenBao reserved for the credentials that genuinely need to rotate every hour.
Frequently Asked Questions
Is External Secrets Operator a replacement for HashiCorp Vault?
No. External Secrets Operator is a delivery mechanism, not a secrets store. It commonly reads from Vault as one of its roughly 41 supported backends, so many production setups run both together rather than choosing one over the other.
Can Sealed Secrets values be rotated automatically?
Not natively. Rotating a sealed value means running kubeseal again with the new value and committing the updated SealedSecret manifest. There is no built-in scheduled rotation the way Vault’s leased credentials or ESO’s refresh interval provide.
Is HashiCorp Vault’s Community Edition still free to use commercially?
Yes, Vault Community Edition remains free to run, including for commercial use, under the Business Source License 1.1 that HashiCorp adopted in 2023. The license restricts building a competing hosted Vault service, not ordinary self-hosted commercial use inside your own infrastructure.
What is OpenBao and why does it matter for this comparison?
OpenBao is a Linux Foundation-governed, MPL 2.0-licensed fork of HashiCorp Vault, created in 2023 in direct response to Vault’s license change. It maintains Vault-compatible APIs, is already a supported backend provider inside External Secrets Operator, and reached v2.7.0 in September 2026.
Does using External Secrets Operator mean secrets are never stored in Kubernetes?
No. ESO fetches a value from an external backend and still creates a plain Kubernetes Secret object inside the cluster by default, so etcd encryption at rest and tight RBAC remain necessary regardless of which tool projects the value in.
Which of these three tools has had the most severe security vulnerabilities?
The Vault Secrets Operator’s CVE-2026-8715, disclosed August 13, 2026 with a 9.6 Critical rating, is the most severe issue on record among the three in the past 18 months. It was fixed within roughly six weeks in VSO 1.5.0. Sealed Secrets has no recorded CVE in the same window.
Can I use more than one of these tools in the same cluster?
Technically yes, they don’t conflict at the Kubernetes API level, and running two in parallel is standard practice during a migration. Running all three permanently in the same namespace as a long-term strategy is generally discouraged, since it multiplies the number of places a misconfiguration can hide.
Do I need a cloud provider account to use External Secrets Operator?
You need some supported backend, but it doesn’t have to be a major cloud provider. ESO’s roughly 41 providers include self-hosted options like Vault and OpenBao, plus SaaS platforms like 1Password, Doppler, and Bitwarden, so a team without an AWS, Azure, or GCP account can still use ESO against one of those alternatives.