Sealed Secrets oder External Secrets Operator? Die Zwischenstufe darfst du überspringen

Häufig liest du: Viele Teams fangen mit Sealed Secrets an und steigen später auf den External Secrets Operator um. Kann man machen. Muss man aber nicht.

Der Unterschied steckt in einer einzigen Frage: Soll dein Passwort verschlüsselt im Git liegen, oder steht im Git nur die Adresse vom Tresor? Kleines Team ohne Druck: Sealed Secrets, und gut ist. Hast du die Zeit: Überspring die Stufe und fang gleich mit dem Tresor an. Und Klartext im Git? Nie.

Die meisten stehen noch eine Etage tiefer

Bevor wir über Werkzeuge reden, mal ehrlich: Viele sind noch gar nicht auf der ersten Stufe. Selbst größere Unternehmen, mit denen ich gesprochen habe, haben keinen Passwort-Safe. Da liegt alles in ganz normalen Kubernetes-Secrets. Warum das kein Schutz ist, steht in einem eigenen Artikel.

Ein Beispiel. Eine Versicherung, IT-Bereich mit rund hundert Leuten. In der Testumgebung lagen die Passwörter erst mal in normalen Kubernetes-Secrets. Irgendwann kam die Überlegung: Wir wollen sicherer werden.

Dann haben sie HashiCorp Vault eingeführt, Schritt für Schritt, und setzen es dort heute ein. Und Sealed Secrets? Kam bei denen nie vor. Direkt vom Klartext in den Tresor, ohne Zwischenhalt.

Sealed Secrets: Briefe im Git, Schlüssel im Cluster

Stell dir Sealed Secrets wie einen Briefkasten vor. Einwerfen kann jeder, der das Zertifikat des Controllers hat. Damit verschlüsselst du dein Secret per kubeseal und committest das Ergebnis ins Git. Aufschließen kann nur der Controller im Cluster. Nicht mal du selbst kriegst den Wert aus dem versiegelten Objekt wieder raus.

Für ein kleines Team ist das richtig angenehm. Kein externer Dienst, nur ein Controller im Cluster. GitOps läuft wie gewohnt.

Der Haken: Alles hängt am Schlüsselbund des Controllers. Der gehört dem Cluster, nicht einzelnen Leuten im Team. Baust du den Cluster neu und hast die Schlüssel nicht gesichert? Dann ist dein Repo voller Briefe, die keiner mehr aufkriegt. Und weil der Controller standardmäßig alle 30 Tage einen neuen Schlüssel an den Bund hängt, sicherst du nicht einmal, sondern immer wieder. Und wer die Sicherung samt Repo erwischt, liest alles.

Passwort tauschen heißt hier: neu versiegeln, committen, ausrollen.

External Secrets Operator: Im Git steht nur die Adresse

Beim External Secrets Operator kommt kein Passwort ins Repo. Auch kein verschlüsseltes. Da liegt nur ein Abholschein: „Datenbank-Passwort, bitte am Tresor abholen.“

Den Rest macht der Operator. Wie er sich beim Tresor anmeldet, legst du in einem SecretStore fest, zum Beispiel über einen Kubernetes-Service-Account. Er holt den Wert. Und er schreibt daraus ein ganz normales Kubernetes-Secret.

Der Tresor ist OpenBao oder HashiCorp Vault oder der Secrets-Manager deines Cloud-Anbieters. Passwort tauschen? Einmal im Tresor ändern, ohne Commit. Der Operator fragt in deinem Takt nach und aktualisiert das Secret. Pods, die den Wert als Umgebungsvariable lesen, musst du trotzdem neu starten, genau wie bei Sealed Secrets.

Klingt super? Hat aber seinen Preis. So ein Tresor fällt nicht vom Himmel. Du betreibst ihn selbst, oder du bezahlst einen Cloud-Dienst dafür. Das ist richtige Arbeit, kein Fingerschnippen.

Meine Ansage

Kleines Team, kein Prüfer in Sicht, keiner drängelt? Dann nimm Sealed Secrets. Heute, nicht nächstes Quartal. Verschlüsselt im Git schlägt Klartext im Git jeden Tag.

Wird das Team größer oder die Umgebung reguliert? Oder hast du einfach die Zeit? Dann spar dir die Zwischenstufe und nimm OpenBao mit dem External Secrets Operator. Oder HashiCorp Vault, da geht auch HashiCorps eigener Vault Secrets Operator. Sonst machst du die Arbeit zweimal: Wer später von Sealed Secrets umzieht, überträgt jeden Wert in den Tresor und ersetzt jedes SealedSecret durch einen Verweis. Die Versicherung hat es genauso gemacht: vom Klartext direkt in den Tresor.

Wie du OpenBao aufsetzt und sauber an Kubernetes anbindest, zeige ich dir im OpenBao-Training am Live-Cluster. Da wohnt das Passwort, wo es hingehört: im Tresor.