External Secrets Operator

Definition

External Secrets Operator (ESO) is an open-source Kubernetes operator that synchronizes secrets stored in external secret-management systems, such as AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, or Google Secret Manager, into native Kubernetes Secret objects. It removes the need to store sensitive values directly in cluster manifests or in a GitOps repository, instead letting an external system of record remain the single source of truth for credentials.

Overview

Kubernetes clusters need a way to hand credentials, API keys, and certificates to running workloads, but native Kubernetes Secrets are only base64-encoded and are frequently checked into the same repositories that describe the rest of the cluster's state. External Secrets Operator addresses the resulting gap between a team's actual secret store and the manifests a cluster consumes, acting as a bridge rather than a store in its own right. Mechanically, ESO introduces two custom resources: a SecretStore (or ClusterSecretStore) that defines how to authenticate against a given backend, and an ExternalSecret that declares which key or path to fetch and which native Secret to write the result into. A controller loop polls the configured backend on an interval, retrieves the current value, and reconciles it into the cluster, refreshing automatically if the upstream value rotates. Provider plugins abstract the differences between vendors so the same ExternalSecret shape works whether the backend is Vault, a cloud KMS-backed store, or a password manager. ESO sits between raw Kubernetes Secrets, which offer no external sync at all, and tools like Sealed Secrets, which take the opposite approach of encrypting a value so it can be committed to Git and only decrypted inside the cluster. Where Sealed Secrets treats the repository as the source of truth, ESO treats the vendor's secret manager as the source of truth and never asks the operator to commit sensitive material anywhere. It also differs from application-level SDKs that call a secrets API directly, because ESO keeps the workload itself unaware that anything beyond a normal Secret mount is involved. In practice, platform teams install ESO cluster-wide and provide each namespace with its own SecretStore scoped to the credentials that namespace is allowed to read, then let application manifests reference an ExternalSecret instead of a bare Secret. This pattern is common in GitOps pipelines managed by Argo CD or Flux, where the desired state must be fully declarative but the actual secret payloads cannot live in Git. Rotation policies configured in the upstream vault propagate to the cluster without a redeploy, provided the workload rereads its mounted secret. The trade-offs are mostly operational: ESO adds another controller and set of CRDs to maintain, its refresh interval means updates are not instantaneous, and misconfigured RBAC on SecretStores can either over- or under-scope access. Teams with a single small cluster and few secrets may find a simpler tool, or even manual sealed values, sufficient, while organizations already standardized on a central vault across many clusters gain the most from the consistency ESO provides.

Key Features

• Supports pluggable backends including AWS, Azure, GCP, and HashiCorp Vault
• Uses SecretStore and ExternalSecret custom resources to declare sync intent
• Automatically refreshes Kubernetes Secrets when the upstream value rotates
• Scopes access per namespace through ClusterSecretStore or namespaced SecretStore
• Keeps sensitive values out of Git repositories entirely
• Integrates cleanly with GitOps controllers such as Argo CD and Flux
• Emits Kubernetes events and metrics for sync failures

Use Cases

Alternatives

Frequently Asked Questions

Related in DevOps