External Secrets Operator
Sync secrets from AWS Secrets Manager, Vault, GCP Secret Manager, and other stores into Kubernetes Secrets — the standard pattern for secrets management in Kubernetes.
Overview
Secrets from an external store
The External Secrets Operator (ESO) is a Kubernetes operator that reads secrets from external stores (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault and others) and syncs them into native Kubernetes Secrets.
The problem it solves
Secret values in plain Kubernetes Secrets are base64-encoded, not encrypted, in etcd. ESO bridges external stores, which handle access control, audit logging, rotation and versioning, with applications that need secrets as environment variables or volume mounts.
The resources
- SecretStore — Namespace — How to authenticate to a backend within a namespace: an IAM role (via IRSA), a Vault token or a GCP service account
- ClusterSecretStore — Cluster — Same, available to all namespaces; for centrally managed backends like a shared Vault cluster
- ExternalSecret — Namespace — Which keys to read and how to write them as a Kubernetes Secret; references a store and maps external key paths to Secret keys; ESO keeps the Secret in sync
IRSA on EKS
> [!TIP] With IRSA, ESO needs no long-term AWS credentials.
Secret rotation
- Environment variables — Only after a pod restart: use the Reloader operator
- Volume mounts — Seamlessly
> [!WARNING] Rotating a secret upstream does nothing for pods reading it from env vars until they restart.
Key concepts
- ExternalSecret
- ESO CRD that defines which secret to read from the external store and how to write it into a Kubernetes Secret. Specifies the SecretStore reference, remote key paths, and target secret name and keys.
- SecretStore
- ESO CRD defining the connection and authentication to a specific secrets backend. Namespace-scoped — only ExternalSecrets in the same namespace can reference it.
- ClusterSecretStore
- Cluster-scoped SecretStore. Any ExternalSecret in any namespace can reference it. Use for shared backends like a central Vault cluster or organization-wide AWS Secrets Manager account.
- IRSA (IAM Roles for Service Accounts)
- EKS mechanism where a Kubernetes service account is annotated with an IAM role ARN. The kubelet exchanges the service account token for AWS credentials via OIDC federation. ESO uses IRSA to call AWS Secrets Manager without static credentials.
- refreshInterval
- ExternalSecret field that controls how often ESO polls the external store for changes. Default is 1 hour. Lower values catch secret rotations faster but generate more API calls against the external store.
- Secrets Store CSI Driver
- Alternative to ESO — mounts secrets directly as files in the pod filesystem using a CSI volume mount, bypassing Kubernetes Secrets entirely. Better for compliance environments that prohibit storing secrets in etcd; ESO is simpler for teams that need standard Kubernetes Secret compatibility.
When to use it
- Syncing secrets from AWS Secrets Manager or Vault into Kubernetes without storing them in Git
- Interview questions about secrets management patterns in Kubernetes
- Implementing automatic secret rotation without manual pod restarts
- Centralizing secret storage and access control across multiple Kubernetes clusters
- Replacing manually created Kubernetes Secrets with GitOps-compatible external sync
Sign up free to read the full topic
More DevOps topics
- eBPF Observability
- eBPF Programming
- Ephemeral and Preview Environments
- etcd and the API Server — The Write Path, Raft, and Why 3 vs 5 Members Matters
- Event-Driven Architecture
- Event-Driven Automation and StackStorm
- Feature Flags
- FinOps & Cloud Cost Engineering
- Firecracker microVMs
- Flux v2
- GCC Toolchain Internals
- GCC Upgrades and ABI Migration
Start free on Cariara · Coding problems · System design studio