External Secrets Operator: complete gids voor installatie en configuratie

Dit is de praktische vervolgstap op ons conceptartikel over de External Secrets Operator: een complete gids om ESO daadwerkelijk te installeren en te configureren, van een lege cluster tot een werkende synchronisatie met een externe secrets manager.

Installatie met Helm

helm repo add external-secrets https://charts.external-secrets.io
helm repo update

helm install external-secrets external-secrets/external-secrets 
  --namespace external-secrets 
  --create-namespace 
  --set installCRDs=true

De vlag installCRDs=true zorgt dat de benodigde custom resource definitions (SecretStore, ClusterSecretStore, ExternalSecret) meteen worden geïnstalleerd. Controleer daarna of de controller-pods draaien:

kubectl get pods -n external-secrets

Stap 1: een SecretStore koppelen aan Vault/OpenBao

Een SecretStore definieert de verbinding met de externe bron, hier gekoppeld via de Kubernetes-authenticatiemethode van Vault/OpenBao:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-backend
  namespace: productie-app
spec:
  provider:
    vault:
      server: "https://vault.voorbeeld.nl:8200"
      path: "secret"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "eso-role"
          serviceAccountRef:
            name: "eso-serviceaccount"

Stap 2: een ExternalSecret aanmaken

De ExternalSecret specificeert wélk geheim opgehaald moet worden, en hoe vaak er gecontroleerd wordt op wijzigingen:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: productie-app
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: database-credentials   # naam van de resulterende K8s Secret
    creationPolicy: Owner
  data:
    - secretKey: wachtwoord
      remoteRef:
        key: database/productie
        property: password

Na het toepassen van beide manifests verschijnt automatisch een gewone Kubernetes Secret database-credentials in de namespace, die door elke pod op de standaard manier gebruikt kan worden — de applicatie hoeft niets van ESO of Vault te weten.

Voor AWS Secrets Manager of Azure Key Vault

Het principe blijft identiek; alleen het provider-blok in de SecretStore verandert:

spec:
  provider:
    aws:
      service: SecretsManager
      region: eu-west-1
      auth:
        jwt:
          serviceAccountRef:
            name: eso-serviceaccount

Controleren en troubleshooten

kubectl describe externalsecret database-credentials -n productie-app

Praktijktip: Verschijnt de Kubernetes Secret niet? Controleer eerst de status.conditions in de output van kubectl describe — meestal wijst dit direct naar een authenticatie- of RBAC-probleem tussen ESO en de externe bron, niet naar de ExternalSecret-definitie zelf.

Vergelijking met Sealed Secrets

Veelgestelde vragen

Werkt ESO ook met meerdere secrets managers tegelijk?

Ja — je kunt meerdere SecretStores definiëren die elk naar een andere provider wijzen, en per ExternalSecret aangeven welke SecretStore gebruikt moet worden.

Wat gebeurt er als de externe bron tijdelijk onbereikbaar is?

De laatst bekende Kubernetes Secret blijft gewoon bestaan; ESO probeert het bij de volgende refreshInterval opnieuw. Er is geen directe impact op al draaiende workloads.