External Secrets Operator: Rotation statt Ticket 2026

Constantin, Kubernetes-Betrieb bei Pexon Consulting | 11 Min. Lesezeit | 16.09.2026

TL;DR: external secrets operator kurz erklärt

Der External Secrets Operator liest Geheimnisse aus einem externen Tresor und schreibt Kubernetes-Secrets, inklusive Refresh. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) trennt diese Sync-Schicht vom Tresor und von RBAC. Rotation ist Intervall plus Tresor-Job. Ohne das klebt das Secret im Ticket.

Das Problem: Secrets sitzen im Ticket, nicht im Tresor

Das Cluster hat Secrets. Sie heißen app-db und smtp. Niemand sagt, woher sie kamen.

Häufiger Ablauf: jemand kopiert den Wert aus einem Ticket, aus einem Chat oder aus einer lokalen Datei. kubectl create secret einmal. Danach lebt das Objekt ewig. Rotation ist ein Kalendereintrag, den niemand besitzt.

Genau hier sitzt der External Secrets Operator. Die Schicht ist Sync: der Operator materialisiert ein natives Secret aus SecretStore oder ClusterSecretStore. Der Tresor bleibt Tresor. RBAC bleibt RBAC.

Wir sehen das in Reviews als Job, nicht als fehlendes Chart. Das Chart läuft. Das Secret ist trotzdem ein einmalig geklebter Blob. Oder Refresh steht auf Stunden, der Tresor rotiert nie. Dann ist ESO Kosmetik.

Pexon Consulting schneidet Secrets deshalb als Review-Frage: wo liegt die Quelle, wer rotiert, wer darf im Namespace lesen.

Was macht der External Secrets Operator – und was bleibt im Tresor?

Der External Secrets Operator materialisiert Kubernetes-Secrets aus einem externen Tresor und kann sie refreshen. Er ersetzt weder RBAC noch den Tresor selbst.

ExternalSecret zeigt auf SecretStore oder ClusterSecretStore. Der Store kennt Vault, Azure Key Vault, AWS Secrets Manager oder GCP Secret Manager. Der Operator schreibt ein natives Secret. Apps mounten wie bisher. Das ist die Definition.

Was der External Secrets Operator ausdrücklich nicht ist:

1. Kein Identity-Provider. Wer den Cluster betritt, entscheidet RBAC, nicht ESO.
2. Kein Tresor. Die Quelle bleibt außen. Wer Vault oder Key Vault nicht betreibt, hat nur den Sync-Teil.
3. Kein Ersatz für Zertifikats-Operatoren. Zertifikate sind eine andere Entity, nicht App-Secrets.
4. Kein Scanner. Trivy findet nackte Secrets. Es synced sie nicht.

GitOps committet die Referenz, nicht den Klartext. Sealed Secrets ist ein anderer Weg: verschlüsselt im Repo, ohne zentralen Tresor. Ein Satz reicht. Zwei Produkte daraus zu machen, verdoppelt nur die Folien.

Stabile Version am 16.09.2026: External Secrets Operator v2.10.0 (Release 28.08.2026). Das Repo external-secrets/external-secrets lag am 16.09.2026 bei 6.860 GitHub-Stars. Offizielle Doku: external-secrets.io.

# Schicht, keine Installationsanleitung. Werte an Ihren Store anpassen.
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: app-db
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: vault-backend
  target:
    name: app-db
    creationPolicy: Owner
  data:
    - secretKey: password
      remoteRef:
        key: prod/app/db
        property: password

refreshInterval: 1h beweist Refresh, nicht Rotation im Tresor. Ohne Job dort bleibt der Wert gleich, der Operator schreibt ihn nur erneut.

Wann bleibt ein Anbieter-Operator oder Key Vault CSI ehrlicher?

Die kurze Antwort: wenn Sie genau einen Tresor und genau einen Mount-Weg haben, und niemand ein natives Secret braucht.

Azure Key Vault CSI mountet als Volume. Das ist ehrlich, solange die App Dateien liest und kein Secret im API-Server erwartet. Sobald Sidecars, Operatoren oder Helm-Values ein natives Secret verlangen, ist CSI der falsche Adapter.

Ein Anbieter-Operator (Infisical und ähnliche) bindet Sie an ein Produkt. ESO ist der generische Sync. Wir raten zum Anbieter-Operator nur, wenn das Haus den Tresor schon als Standard gesetzt hat und kein zweites Sync-Objekt will. Sonst ESO, ein Store, eine CRD.

Wann wir davon abraten: drei Stores, drei Operatoren, keine Besitzfrage. Das ist teurer als ein fehlendes Chart.

CSI plus ESO parallel für dasselbe Secret ist die Variante, die Reviews am häufigsten als Drift finden. Eine Quelle, ein Materialisierungsweg. Den zweiten Weg streichen, nicht dokumentieren.

DataForSEO nannte am 16.09.2026 für external secrets operator 590 Suchen, LOW. Das rechtfertigt das Lemma, nicht einen Vault-Vs-Roman und nicht eine zweite Money-Page.

Wie hängt ESO mit GitOps, RBAC und einem Secret-Scan zusammen?

GitOps committet ExternalSecret und Store-Referenz. Der Klartext bleibt im Tresor. Wer das Secret ins Manifest schreibt und ESO „danach auch noch“ installiert, hat zwei Wahrheiten.

RBAC entscheidet, wer get secret im Namespace darf. ESO ändert das nicht. Ein sauberer Sync mit view für die halbe Plattform ist immer noch ein Leck. Der Review fragt nach RoleBinding, nicht nach der CRD-Version.

Ein Scan findet Klartext in Image, Git oder Ticket. Das ist Befund, kein Sync. Die 32-Punkte-Checkliste bleibt Praktiken. Falco, Kyverno und Trivy sind eigene Schichten. Diesen Text nicht mit deren SERPs mischen.

Unsere Empfehlung: erst Quelle und Rotation, dann Refresh-Intervall, dann wer lesen darf. Chart zuletzt. Wer mit dem Chart beginnt, hat nach zwei Sprints immer noch Tickets mit Passwörtern.

Wie prüfen Sie in einem Cluster Review, ob Rotation wirklich läuft?

Vier Fragen, keine Installationsschritte.

1. Wo liegt die Quelle? Vault, Key Vault, AWS SM, eine Datei, ein Ticket.
2. Wer rotiert dort, in welchem Intervall, mit welchem Nachweis?
3. Welches refreshInterval hat ExternalSecret, und landet die Änderung im nativen Secret?
4. Wer darf das Secret im Namespace lesen, nach dem Sync?

Wenn eine der vier unbeantwortet bleibt, ist ESO vorhanden und die Schicht trotzdem offen. Das ist die Review-Finding. Pexon Consulting (Microsoft Partner) schreibt sie als Betriebsgrenze, nicht als Chart-Ticket.

Eine Probe: Wert im Tresor ändern, Intervall abwarten oder Reconcile anstoßen, Secret im Cluster muss den neuen Wert zeigen. Kein neuer Wert, keine Rotation. Nur ein Objekt namens ExternalSecret.

Was wir nicht anfassen: ein Infisical-Portrait, ein Vault-Vs als H1, Klartext-Beispiele mit echten Tokens, die WAF-LP, Runtime- oder Admission-Tutorials. Focus bleibt external secrets operator.

In regulierten Häusern reicht „wir haben ESO“ als Satz in der Richtlinie nicht. Die Revision fragt nach dem letzten rotierten Secret. Wenn die Antwort „steht im Ticket vom Onboarding“ ist, ist die Schicht organisatorisch tot, technisch aber grün.

SecretStore gilt im Namespace. ClusterSecretStore gilt clusterweit. Beides ist dieselbe Entity, unterschiedlicher Scope. Ein ClusterSecretStore, den jedes Team beschreiben darf, ist praktisch ein zweites Ticket: die Quelle ist zentral, der Zugriff nicht. Wir raten zu wenigen Stores, benannten Besitzern, und ExternalSecret nur dort, wo die App das native Secret wirklich braucht.

Refresh ist kein Beweis. Der Operator kann stündlich schreiben und trotzdem denselben Hash liefern. Deshalb die Probe mit geändertem Wert. Ohne die Probe bleibt ESO ein Objekt im kubectl get.

Was wir in lebenden Clustern häufiger sehen als „ESO fehlt“: Store zeigt auf eine alte App-Registration, Refresh steht auf 24h, niemand besitzt die Rotation im Tresor, und get secret haben drei Teams. Das Chart ist grün. Der Job ist offen.

Pexon Consulting bleibt dabei Berater, der den Cluster schon vorfindet. Wir installieren nicht gegen eine leere Lab-Folie. Wir prüfen, ob Sync eine Betriebsfähigkeit hat. v2.10.0 vom 28.08.2026 ist der aktuelle stabile Zweig, kein Grund, jede RC mitzuziehen.

Häufig gestellte Fragen

Gehören Secrets ins Git?

Nein, nicht als Klartext. GitOps committet die Referenz (ExternalSecret, Store). Sealed Secrets verschlüsselt ins Repo, das ist ein anderer Weg. Beides ist besser als kubectl create secret aus einem Ticket.

Was kostet der External Secrets Operator im Betrieb?

Die Software ist Open Source. Geld sitzt in Tresor-Betrieb, Rotation und den Leserechten. Einen Listenpreis für das Chart gibt es nicht. Der Einstieg bei uns ist der 45-Minuten-Cluster-Check, kein Lizenzverkauf.

Ist ESO dasselbe wie ein Key Vault CSI Driver?

Nein. CSI mountet oft als Volume. ESO schreibt ein natives Secret. Braucht die App ein Secret-Objekt, ist CSI der falsche Adapter. Braucht sie nur Dateien und einen Azure-Tresor, kann CSI ehrlicher sein.

Reicht ESO ohne Rotation im Tresor?

Kommt darauf an, aber meist nein. Refresh ohne Tresor-Job schreibt denselben Wert erneut. Das sieht nach Sync aus und ist keiner. Rotation sitzt zuerst außen.

Ersetzt ESO ein Security-Audit?

Nein. Sync und Rotation sind eine Schicht im Review. Admission, Runtime und WAF bleiben eigene Texte. Diesen Artikel nicht mit deren Keywords verwechseln.

Nächster Schritt

Verwandte Themen