External Secrets Operator
Kubernetes operator that syncs secrets from external secret management systems (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, GCP Secret Manager, Doppler, Infisical, etc.) into Kubernetes Secrets. Enables GitOps workflows where secret references (not values) are stored in Git, while actual values remain in secure external stores. ExternalSecret resources define what to fetch and how to map to Kubernetes Secrets — operators pull values periodically and keep Kubernetes Secrets in sync.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Apache 2.0, actively maintained. Secrets stored in external managers — not in Git or etcd plaintext. IRSA/Workload Identity for cloud-native auth. Secrets only exist in Kubernetes Secrets (etcd) not in operator state. Follow K8s RBAC best practices.
⚡ Reliability
Best When
You use Kubernetes and store secrets in external managers (AWS SM, Vault, GCP SM) but need them available as native Kubernetes Secrets for app compatibility.
Avoid When
You need dynamic secrets (database creds generated per-pod) — use Vault Agent Injector or Vault CSI directly.
Use Cases
- • Sync secrets from AWS Secrets Manager/GCP Secret Manager into Kubernetes Secrets without storing plaintext in Git — GitOps-compatible secrets management
- • Federate secrets across multiple Kubernetes clusters from a single source of truth (Vault, AWS SSM) using ClusterSecretStore
- • Automatically rotate Kubernetes Secrets when source secrets are rotated in external managers — eliminates manual rotation
- • Reduce IRSA/Workload Identity complexity by having one ESO service account with secret access rather than per-pod roles
- • Enable agent workloads to access secrets via standard Kubernetes Secrets API while actual values are managed in enterprise secret stores
Not For
- • Dynamic short-lived secrets — Vault Agent Injector or Vault CSI provider are better for dynamic credential generation
- • Teams without Kubernetes — ESO is specifically for Kubernetes secret injection
- • Replacing Vault entirely — ESO is a sync mechanism, not a secrets engine; it requires an external store to pull from
Interface
Authentication
ESO authenticates to external stores using cloud IAM (IRSA for AWS, Workload Identity for GCP), service account tokens, or static credentials stored in Kubernetes Secrets. ESO itself doesn't expose an API — it's a Kubernetes operator driven by CRD specs.
Pricing
Apache 2.0 licensed. No commercial version. You pay for the external secrets manager (AWS SM, Vault, etc.) but not ESO.
Agent Metadata
Known Gotchas
- ⚠ Secrets are pulled on schedule (default 1 hour) — immediate rotation requires manually annotating ExternalSecret to force sync
- ⚠ ExternalSecret CRD references SecretStore or ClusterSecretStore for external provider config — both must exist before ExternalSecret works
- ⚠ IAM permissions for ESO service account must cover all secrets it needs to read — missing permissions cause sync failures
- ⚠ Template feature for secret value transformation (base64, JSON extraction) has its own syntax — test templates carefully
- ⚠ Deleting a Kubernetes Secret created by ESO doesn't delete the source in the external store — ESO will recreate the K8s Secret on next sync
- ⚠ creationPolicy and deletionPolicy in ExternalSecret spec control merge/owner behavior — incorrect policy causes unexpected Secret mutations
- ⚠ Rate limits on external stores (AWS SM API throttling) can cause sync failures in clusters with many ExternalSecret resources
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for External Secrets Operator.
Scores are editorial opinions as of 2026-03-06.