Last modified August 20, 2026

External Secrets Operator

External Secrets Operator (ESO) is a Kubernetes operator that reads secrets from an external source and delivers them securely as Kubernetes secrets for your workloads to consume.

We make ESO available on all management clusters, and also as a managed application for you to deploy on your workload clusters. To install and use it, follow using External Secrets Operator.

ESO binds secrets into the cluster that would otherwise have required you to commit them to source control or deploy them manually. The full upstream documentation lives on the External Secrets Operator website.

How ESO relates to SOPS

You can run ESO either alongside, or in place of, SOPS. There’s no hard and fast rule around choosing one over the other.

Both can coexist on the same cluster, as long as the secrets they manage are independent of one another. A secret created with SOPS shouldn’t be updated or managed with ESO, and vice versa. Otherwise the two tools end up fighting each other, and neither becomes the source of truth for that secret.

Do you have many secrets currently handled by SOPS? ESO can take them over, as long as it supports the provider you want to move to. SOPS works to your advantage here, because it’s embedded into Flux. You can migrate gradually, without disrupting your platform.

Risks to weigh

Every application carries risk, and the primary one here is availability. Say ESO isn’t running and credentials are rotated in your secret provider. The Kubernetes secrets ESO manages no longer match the provider, so your applications may fail on deployment or when they scale.

Plan for this the way you would for any other control-plane dependency. Monitor the operator, and keep in mind that a rotation during an ESO outage is the scenario that hurts.