External Secrets Operator — Sync Secrets from Any Vault to Kubernetes

What it is

External Secrets Operator (ESO) is a CNCF project that synchronizes secrets from external management systems into Kubernetes Secret objects. It supports over 25 backends including AWS Secrets Manager, HashiCorp Vault, Google Cloud Secret Manager, Azure Key Vault, 1Password, and Doppler.

ESO targets platform engineers running Kubernetes clusters who need secrets from external vaults available as native Kubernetes Secrets. Instead of baking secrets into manifests or using init containers, ESO declares what secrets you need and keeps them synchronized.

How it saves time or tokens

This workflow provides the Helm installation commands and a working ExternalSecret manifest. Instead of reading through ESO documentation to understand CRDs and provider configuration, you get a copy-paste setup that connects to your vault provider in minutes.

How to use

1. Install ESO via Helm:

helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets \
  -n external-secrets --create-namespace

1. Create a SecretStore that points to your vault provider:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secrets
spec:
  provider:
    aws:
      service: SecretsManager
      region: us-east-1
      auth:
        secretRef:
          accessKeyIDSecretRef:
            name: aws-creds
            key: access-key-id
          secretAccessKeySecretRef:
            name: aws-creds
            key: secret-access-key

1. Create an ExternalSecret to sync a secret:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: my-app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets
  target:
    name: my-app-secrets
  data:
    - secretKey: database-url
      remoteRef:
        key: prod/my-app/database-url

Example

# ClusterSecretStore for org-wide Vault access
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: vault-store
spec:
  provider:
    vault:
      server: 'https://vault.internal:8200'
      path: 'secret'
      version: 'v2'
      auth:
        kubernetes:
          mountPath: 'kubernetes'
          role: 'external-secrets'

Related on TokRepo

• Security tools -- Secret management and security scanning
• DevOps tools -- Kubernetes and infrastructure automation

Common pitfalls

• Forgetting to set the refreshInterval means secrets are only fetched once. Set it to a reasonable value (e.g., 1h) so rotated secrets propagate to your cluster.
• Using SecretStore instead of ClusterSecretStore when you need cross-namespace access. ClusterSecretStore is cluster-scoped and accessible from any namespace.
• IAM permissions are the most common setup failure. Ensure your cloud credentials have read access to the specific secrets you reference.