External Secrets Operator (ESO)

External Secrets Operator (ESO) is a Kubernetes operator that copies secrets from an external secret manager, such as HashiCorp Vault, AWS Secrets Manager, Google Secret Manager or Azure Key Vault, into ordinary Kubernetes Secrets. The password lives in the secret manager, the cluster gets a copy that ESO keeps up to date, and no secret value is committed to Git.

How it works

ESO adds two main custom resources. A SecretStore, or the cluster-wide ClusterSecretStore, says how to reach a provider and authenticate to it, for example Vault with Kubernetes auth. An ExternalSecret says which remote keys to fetch, which Kubernetes Secret to write and how often to refresh. The controller reconciles each ExternalSecret on that interval and creates or updates the target Secret.

Exercise 7 of the One2N SRE bootcamp runs Vault in the cluster as the secret store for ESO. In a setup like that, an ExternalSecret with refreshInterval: 1h and a secretStoreRef pointing at the Vault SecretStore maps property password of Vault key db to DB_PASSWORD in Secret student-api-db. ESO checks Vault 24 times a day, so a rotated password reaches the Secret within an hour, and the API pod reads it through secretKeyRef.

Why it matters in production

ESO gets the secret into the cluster; it does not make it safe there. A Kubernetes Secret is base64-encoded, not encrypted, so limit who can read Secrets with RBAC and turn on encryption at rest for etcd. Environment variables are read once at container start, so pods need a restart, or a mounted volume, to pick up a rotated value. Watch the ExternalSecret's Ready condition as well: if ESO loses access to the store, the last synced Secret stays in place and nothing fails until the password changes.