Vault vs External Secrets Operator

HashiCorp Vault vs External Secrets Operator (ESO): choosing between a full secrets platform and a Kubernetes-native secret sync operator.

kubernetessecuritysecretsvaulteso

Back to Toolkit

Feature Matrix	HashiCorp Vault Full-featured secrets management platform with dynamic secrets, PKI, and audit logging.	External Secrets Operator Kubernetes operator that syncs secrets from cloud providers (AWS, GCP, Azure) into K8s Secrets.
Architecture Vault is a secrets engine; ESO is a bridge to existing cloud secret stores.	Self-hosted secrets platform (runs in cluster or standalone)	Kubernetes operator — syncs secrets from external stores
Dynamic Secrets Vault generates short-lived credentials for databases, AWS IAM, PKI. ESO only reads static secrets.
Secret Backends ESO is an aggregator — it can even use Vault as a backend.	KV, AWS, GCP, Azure, databases, PKI, SSH, TOTP, and more	AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, Vault, 1Password, and more
PKI / Certificate Management Vault's PKI secrets engine issues and rotates TLS certificates natively.
Operational Complexity Vault requires significant ops investment to run reliably at scale.	High — HA setup, storage backend, unsealing, DR	Low — Helm install, RBAC, cloud credentials
Audit Logging For compliance, Vault's centralized audit log is often required.	Comprehensive audit trail per secret access	Relies on cloud provider audit logs
Secret Rotation Vault rotates actively; ESO re-reads when the upstream version changes.	Native (database creds, cloud keys)	Passive (re-syncs on schedule or secret version change)
Cost ESO itself is free. You pay for the secret store (e.g., AWS Secrets Manager at $0.40/secret/month).	Source-available (BSL license) or Vault Enterprise (costly)	Open source (Apache 2.0) + cloud secret store costs
Multi-cloud Both handle multi-cloud. Vault centralizes; ESO federates.	Yes — single Vault instance serves all clouds	Yes — can aggregate from multiple backends simultaneously

Overview

Vault and ESO solve related but different problems. ESO is a Kubernetes operator that bridges cloud-native secret stores (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) into Kubernetes Secrets. It's lightweight, easy to install, and doesn't require you to run any additional infrastructure. Vault is a full secrets management platform that provides dynamic credential generation, PKI, audit logging, and its own KV store — but requires significant operational investment to run reliably. In 2026, most teams are choosing ESO unless they have a specific requirement that only Vault can satisfy.

Where ESO Wins

ESO is the right choice when you already use cloud-native secret stores. If your secrets live in AWS Secrets Manager or Parameter Store, ESO syncs them into Kubernetes Secrets with zero additional infrastructure. Setup takes 20 minutes: install via Helm, create a SecretStore pointing at your cloud credentials, and write ExternalSecret CRDs. ESO also supports rotation passively — when the upstream secret version changes, ESO re-syncs automatically. For teams that want GitOps-friendly secret management without running Vault, ESO is the default choice.

Where Vault Wins

Vault is essential when you need dynamic secrets. Vault's database secrets engine generates short-lived Postgres, MySQL, or MongoDB credentials that expire in minutes — eliminating the risk of long-lived credentials leaking. Its PKI engine issues and rotates TLS certificates without cert-manager. Its AWS secrets engine generates temporary IAM credentials. If your compliance requirements demand a centralized audit trail (who accessed what secret, when), Vault's audit log is also far more comprehensive than relying on individual cloud provider logs.

Migration & Switching Cost

Migrating from Vault to ESO requires identifying all Vault KV paths, migrating static secrets to a cloud secret store (AWS Secrets Manager, etc.), and replacing VaultSecret/Agent Injector annotations with ExternalSecret CRDs. Dynamic secrets cannot be migrated — you'll need to replace them with IAM roles (IRSA) or database users with shorter TTLs. Going the other direction (ESO → Vault) requires deploying and hardening Vault (HA, auto-unseal, DR replica) before any migration — budget 2–4 weeks of ops work.

Final Verdict

For most Kubernetes teams in 2026, start with ESO. It requires no additional infrastructure, integrates naturally with cloud-native secret stores, and covers 90% of secret management needs. Add Vault only when you need dynamic database credentials, PKI/TLS issuance, or a centralized audit log that spans multiple cloud providers.

Kubernetes Secrets Management: Vault vs External Secrets Operator

A deep dive into secrets management patterns for Kubernetes, comparing HashiCorp Vault with the External Secrets Operator.

Read the Blog Post

Vault vs External Secrets: how to choose

These two are frequently compared and are not substitutes, which is the single most useful thing to know before choosing. Vault is a secret store: it holds secrets, issues dynamic credentials, and enforces policy on access. External Secrets Operator holds nothing — it is a Kubernetes controller that reads from a backend and materialises the result as a native Kubernetes Secret.

That backend is very often Vault. "Vault vs ESO" usually turns out to be "how should Kubernetes consume Vault", and ESO is one valid answer to it. The others are HashiCorp's own Vault Secrets Operator, the Vault Agent injector sidecar, or the application talking to Vault directly.

The genuine trade-off is where the secret ends up. ESO writes a Kubernetes Secret, which means anything with read access to that namespace can read it, and it sits in etcd. Direct Vault integration keeps the secret out of the Kubernetes API and supports short-lived dynamic credentials, at the cost of the application or a sidecar knowing about Vault.

What each one actually is

	Vault	External Secrets Operator
Category	Secret store and identity broker	Synchronisation controller
Stores secrets	Yes — it is the source of truth	No — reads from a backend you already have
Dynamic credentials	Yes: short-lived database, cloud and PKI credentials issued on demand	No — it syncs whatever the backend holds
Where the secret lands	In the app, a sidecar, or a mounted file; not necessarily in etcd	A native Kubernetes Secret, stored in etcd
Backends supported	N/A — it is the backend	Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager and many more
Operational cost	Real: unsealing, HA, upgrades, policy and audit	Low: one controller, no state of its own

The pattern most teams end up with

A common and defensible setup: a cloud provider's secret manager or Vault as the source of truth, ESO syncing the subset that Kubernetes workloads need, and the applications reading ordinary environment variables or files. Nothing in the application knows about the secret backend, which keeps the code portable and the onboarding simple.

Move away from that pattern when you need what only dynamic credentials give you — a database password that exists for an hour and is unique per pod, so a leaked credential is worth almost nothing and revocation is automatic. That requires integrating with Vault properly, through the Vault Secrets Operator, the agent injector, or the application itself. It is more work, and for high-value databases it is usually the right work.

Frequently asked questions

Can I use both together?

Yes, and it is the most common production arrangement. Vault is the source of truth and the policy engine; ESO projects the static secrets that workloads need into Kubernetes. Use direct Vault integration for the credentials that should be short-lived and per-workload, and ESO for the ones that are genuinely static, like a third-party API key.

Is putting secrets in Kubernetes Secrets safe?

Acceptable with care, and worse than not doing it. Enable encryption at rest for etcd, restrict RBAC on Secrets to the namespaces that need them, and remember anyone who can create a pod in a namespace can usually read its secrets. If a secret is valuable enough that this bothers you, that is the signal to use dynamic short-lived credentials instead of protecting a static one better.

Do I need Vault if my cloud has a secret manager?

Often not. AWS Secrets Manager, Azure Key Vault and Google Secret Manager cover storage, rotation and IAM-based access well, and cost far less operational effort than running Vault. Vault earns its keep when you need dynamic credentials across many systems, PKI issuance, encryption as a service, or a single secret plane spanning clouds and on-premises. Running Vault to store static strings in one cloud is usually over-engineering.

What is the difference between ESO and HashiCorp's Vault Secrets Operator?

ESO is backend-agnostic — one controller, many providers — which matters if you use more than one secret store or expect to change. VSO is HashiCorp's own and integrates more deeply with Vault-specific features, including dynamic secrets and their lifecycle. Choose ESO for breadth and a consistent interface, VSO when you are all-in on Vault and want its advanced capabilities.