SYSTEM Cited by 1 source

External Secrets Operator (ESO)

External Secrets Operator (ESO) is a CNCF Kubernetes operator that reads secrets from external secret stores (AWS Secrets Manager, AWS Systems Manager Parameter Store, HashiCorp Vault, GCP Secret Manager, Azure Key Vault, etc.) and writes them as native Kubernetes Secret objects on a recurring sync cadence — giving pods access to externally-managed secrets without requiring application code changes, daemonsets, or volume mounts. Stub page — expand on future ESO-internals sources.

What problem it solves

Three rival approaches in K8s clusters, and why ESO won at Generali:

Approach	Problem
Hard-coded secrets in Deployment manifests	"not recommended" — plaintext in Git, no rotation
Native K8s Secret objects managed manually	no rotation, no audit trail, no source of truth
CSI driver mounting secrets as volumes	conflicts with stateless-only / no-volume-mount discipline; adds a daemonset
External Secrets Operator → K8s Secret → env var	no daemonset, no mount, no code changes, automatic sync

The last row is the idiomatic shape for stateless-only EKS clusters where volume mounts are structurally avoided.

Operating model

1. Cluster-admin declares an ExternalSecret custom resource: "sync these named AWS Secrets Manager entries to a K8s Secret in namespace X on a 1-hour interval".
2. ESO controller authenticates (typically via IRSA — IAM roles for service accounts) to AWS.
3. On each tick, ESO reads current secret values from Secrets Manager and writes / updates the corresponding K8s Secret objects in the target namespace.
4. Pods consume the Secret as env vars (or as files via the standard K8s secret-mount mechanism, for workloads that prefer it).
5. When Secrets Manager rotates a value, the next ESO tick propagates the update into K8s; pods can be restarted (or watch the Secret) to pick up the new value.

Generali explicitly chose the env-var consumption path because their stateless-only discipline avoids all volume mounts.

Benefits framed by Generali

• "Improved security, management, and auditability of secret usage through centralized secret management outside their Kubernetes clusters."
• "Automatic secret synchronization on a recurring basis to capture credential rotations."
• "Without requiring application code changes or daemonsets." The last clause is a direct contrast with CSI-driver approaches.

Seen in

• sources/2026-03-23-aws-generali-malaysia-eks-auto-mode — Generali's chosen secret-injection mechanism on EKS. Pairs with stateless-only pods + env-var injection for maximum operational simplicity.

Related

• systems/aws-secrets-manager — the source of truth.
• systems/kubernetes, systems/aws-eks — the consumer platform.
• concepts/stateless-compute — ESO's env-var injection path is a direct consequence of the stateless-only / no-volume-mount discipline.