ReviseAlgo Logo

Kubernetes Configuration & Secrets

External Secrets — Vault, AWS SSM, and External Secrets Operator

Syncing enterprise secrets directly into Kubernetes workloads securely.

Interview: GitOps and enterprise credential management questions frequently target this topic. Understand how the External Secrets Operator (ESO) works as a controller that syncs credentials from external managers (like HashiCorp Vault or AWS SSM) into native Kubernetes Secrets dynamically.

Last Updated: June 15, 2026 • 10 min read

The GitOps Secret Leakage Problem

In a declarative GitOps workflow, all Kubernetes manifests are stored in a Git repository. Because standard Secrets are only base64 encoded, storing secret manifests in Git exposes credentials to anyone with repository access.

To solve this, credentials should be managed in a dedicated Key Management Service (KMS) like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault.

External Secrets Operator (ESO)

The **External Secrets Operator (ESO)** is a Kubernetes operator that integrates with external secret management systems. It runs a controller reconciliation loop that reads API credentials from external managers and automatically generates native Kubernetes Secrets inside your cluster namespace.

How ESO Works

  1. A administrator configures a **SecretStore** defining connection details and authentication parameters to the external KMS (e.g. AWS IAM role or Vault authentication token).
  2. A developer creates an **ExternalSecret** manifest specifying which secret keys to fetch and mapping them to a local Kubernetes Secret name.
  3. The ESO controller continuously polls the external manager API and generates/updates the native Kubernetes Secret accordingly.

ESO Manifest Examples

Here is a configuration declaring a connection to HashiCorp Vault, along with an ExternalSecret that maps Vault keys: