Contents

Infrastructure & Operations › Cloud Computing

External Secrets in Kubernetes

Syncing secrets from a vault into the cluster safely.

Also known as: external secrets, secrets operator, secret syncing

A Kubernetes Secret is only base64-encoded and lives in the cluster’s datastore, so it isn’t a great place to be the source of truth for credentials. The external secrets pattern keeps secrets in a dedicated manager — a cloud secret manager or a vault — and syncs the values into the cluster at runtime. Operators such as the External Secrets Operator, or the secrets-store CSI driver, implement it: you declare which remote secret a Kubernetes Secret should reflect, and a controller fetches it and keeps it current.

# apiVersion depends on the operator version you install
kind: ExternalSecret
metadata: { name: db-password }
spec:
  secretStoreRef: { name: cloud-secrets }
  target: { name: db-password }
  data:
    - secretKey: password
      remoteRef: { key: prod/db, property: password }

The payoff is a single source of truth. Credentials are managed, audited and rotated in one place; the cluster gets a fresh copy instead of a copy someone pasted into a manifest. Secrets never sit in git.

The classic mistakes:

  • Keeping secrets in git anyway. If a value is committed in a manifest, the external manager isn’t the source of truth. Reference remote secrets; don’t inline values.
  • Syncing without rotation. A synced Secret can still be a long-lived copy. Make the flow pull updated values (and restart or reload the workload) when the upstream secret changes, so rotation actually takes effect.
  • Over-broad access. The controller needs permission to read the remote secrets and write Kubernetes Secrets. Scope it tightly — one cluster, one set of paths — not account-wide. See least privilege and RBAC.
  • Ignoring blast radius. A compromised controller or service account could fetch many secrets. Limit which secrets it can reach and in which namespace.
  • Assuming it’s automatic everywhere. Some setups only sync at pod start; a rotated secret needs the pod to pick it up. Know which behaviour you have.

This pattern is a practical layer of secrets management: the cluster consumes secrets without becoming their home. It costs an operator and the permissions it needs, so it’s worth it when you have real secrets and a real manager — not for a single throwaway token.