External Secrets Operator: Sync Secrets into Kubernetes

Why it exists

Storing secrets in Git is a major security risk, and manually managing Kubernetes Secrets is cumbersome and prone to error. Centralized systems like HashiCorp Vault or AWS Secrets Manager solve this at scale, but applications inside Kubernetes need a way to access them securely. External Secrets Operator (ESO) was created to bridge this gap, automating the synchronization from a central source of truth to the cluster.

The mental model

Think of ESO as a trusted courier for your cluster. You give it credentials to an external vault (the SecretStore). Then, you write a manifest (the ExternalSecret) that tells the courier, "Go to this vault, fetch the secret named 'db-password', and deliver it into a Kubernetes Secret named 'my-app-db-creds'." The courier keeps the local copy up-to-date with the vault. Your application only ever talks to the local Kubernetes Secret, unaware of the courier's work.

How it works

ESO extends Kubernetes with Custom Resource Definitions (CRDs). The two most important are SecretStore and ExternalSecret. A SecretStore (or ClusterSecretStore for cluster-wide access) defines how to connect and authenticate to an external provider like Azure Key Vault or Google Secrets Manager. An ExternalSecret resource points to a SecretStore and specifies which secret to fetch from the provider and what the resulting native Kubernetes Secret should be named. The operator's controller runs in the cluster, watches for these resources, fetches the data from the external API, and creates or updates the target Kubernetes Secret.

When to use it

Use ESO when you need to manage secrets centrally for multiple clusters or for both Kubernetes and non-Kubernetes applications. It is essential for a secure GitOps workflow, as it keeps sensitive values out of your repository. It's also ideal for enforcing security policies like secret rotation, as the rotation is handled in the external provider and automatically synced to the cluster.

When not to use it

For simple, single-cluster setups with few static secrets, the overhead of managing an external provider plus the operator might be unnecessary. It also introduces a runtime dependency: if the external provider is down or unreachable when a pod starts or a secret needs refreshing, the operation will fail. This could prevent your applications from starting or receiving updated credentials.

One canonical example

A team uses AWS Secrets Manager to store database credentials. In their Kubernetes cluster, they deploy an ExternalSecret manifest that references a SecretStore configured with an AWS IAM role. The ExternalSecret specifies the remote secret to fetch. The ESO controller uses the IAM role to fetch the JSON secret from AWS, extracts the username and password, and injects them into a Kubernetes Secret named db-creds. The application pod simply mounts the db-creds Secret, completely unaware of AWS.