External Secrets Operator: Sync Secrets into Kubernetes

WHY IT EXISTS: Storing secrets in Git is a major security risk, and managing native Kubernetes Secrets manually is cumbersome and hard to audit. Applications need a way to access secrets from a secure, centralized source of truth—like a cloud provider's secret manager—without being tightly coupled to that specific provider's API.

THE MENTAL MODEL: Think of the External Secrets Operator (ESO) as a trusted courier inside your Kubernetes cluster. You give it a manifest (an ExternalSecret resource) that says, "Go to this vault, get the secret named 'db-password', and put its value inside a Kubernetes Secret named 'my-app-db-creds'." The courier continuously checks if the source has changed and updates the destination, but it never stores the secret itself.

HOW IT WORKS: First, you install the operator in your cluster. Second, you create a SecretStore or ClusterSecretStore resource, which tells ESO how to authenticate with your external secret manager (e.g., AWS Secrets Manager, HashiCorp Vault). Finally, for each set of secrets your application needs, you create an ExternalSecret resource. This resource points to the SecretStore and specifies which external secret keys to fetch and which Kubernetes Secret to create or update with their values. The operator's controller handles the entire synchronization loop.

WHEN TO USE IT: Use ESO when your organization already uses a dedicated secret management system and you want to follow GitOps principles. It allows you to commit application configurations safely to Git, referencing secrets without storing their actual values. This centralizes secret rotation, access policies, and audit trails in the external system.

WHEN NOT TO USE IT: For very simple projects with minimal security requirements, ESO might be overkill, as it adds another component to manage. If you have no external secret manager and are not planning to adopt one, other solutions like Sealed Secrets might be a better fit. ESO is a synchronizer, not a secret store itself.

ONE CANONICAL EXAMPLE: A web application's Helm chart needs a database password. Instead of passing the password as a chart value, you commit an ExternalSecret manifest. This manifest instructs ESO to fetch the prod/db/password key from HashiCorp Vault and create a Kubernetes Secret named webapp-db-secret. The application's Deployment manifest then mounts this webapp-db-secret just like any other native secret, completely unaware that ESO or Vault exist.