Last modified August 20, 2026

Using External Secrets Operator

External Secrets Operator (ESO) reads secrets from an external secret manager and delivers them as Kubernetes secrets. This guide covers installing it on a workload cluster and creating the two resources you need to start pulling secrets.

For what ESO is, how it compares to SOPS, and the risks of depending on it, read External Secrets Operator.

Note: ESO needs three additional pods, 300m of CPU, and 1.5GiB of memory once running. Installs and upgrades temporarily need up to 1.5GiB more, because the CRD installer pod caches Kubernetes resources. That extra usage is released as soon as the install job completes.

Install ESO

Install ESO on your workload cluster as a managed app from our catalogs. No special or additional configuration is required. Create an App resource (or a Flux HelmRelease) against the cluster using our GitOps approach, or use our web UI.

Note: The App custom resource shown below is being phased out in favor of Flux HelmRelease. For new deployments, see Deploying an application via a Flux HelmRelease.

Example App resource

---
apiVersion: application.giantswarm.io/v1alpha1
kind: App
metadata:
  name: external-secrets
  namespace: abc123
spec:
  catalog: giantswarm-catalog
  kubeConfig:
    inCluster: false
  name: external-secrets
  namespace: org-example
  userConfig:
    configMap:
      name: external-secrets-userconfig-abc123
      namespace: abc123
  version: 0.4.2

To configure specific parts of the values yourself, start from the application chart at giantswarm/external-secrets. For the configuration options the app platform offers, see app configuration.

Create a SecretStore

Using ESO requires two resources on your cluster. Create the SecretStore first.

The secret store binds ESO to your secret manager, whether that’s AWS KMS, Azure Key Vault, Hashicorp Vault, or another of the many supported secret providers.

You can define multiple SecretStores on the cluster. This works best inside a multi-tenant environment. Different teams may have different secret providers, or only have restricted access to part of the secret provider, as is the case with Hashicorp Vault Enterprise.

Create an ExternalSecret

Next, create the ExternalSecret. Here you bind one or many external secrets to the Kubernetes secret that this resource manages.

An ExternalSecret may bind several secrets to one Kubernetes secret. Where it does, it may only reference a single SecretStore. For details, see binding multiple secrets.