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

Start free on Cariara · Coding problems · System design studio