Ein Kubernetes-Secret ist so geheim wie eine Postkarte

Ganz ehrlich: Ich weiß genau, wann ein Teilnehmer merkt, dass er reingelegt wurde. Es ist immer derselbe Moment, in praktisch jedem Einführungstraining, das ich gebe.

Der Moment, in dem’s jedem die Sprache verschlägt

Ein Passwort rein ins Secret, Übung läuft glatt - bis im YAML das Feld data auftaucht und jemand fragt, warum das so kryptisch aussieht. Und dann wird sofort klar: Das ist gar nicht verschlüsselt, das ist nur base64-codiert - am Muster erkennt man das auf den ersten Blick. Dekodieren zeige ich gleich zweimal: den schnellen Weg direkt aus dem Cluster, kubectl get secret <name> -o jsonpath='{.data.password}' | base64 -d, und den Handwerker-Weg zum Nachvollziehen - Wert kopieren, base64 -d drüberjagen, geht natürlich genauso. Zehn Sekunden, fertig, Passwort steht da. Komplett lesbar. Der Raum wird jedes Mal ein bisschen leiser.

Meine Quintessenz, die ich danach jedes Mal sage: Ein Secret ist keine Möglichkeit, ein Passwort zu schützen. Secret - der Name ist schlicht irreführend, und warum er trotzdem so gewählt wurde, bleibt offiziell im Dunkeln. Fakt ist nur: Es ist ein simpler base64-codierter Wert, nicht mehr und nicht weniger. Meine Vermutung, die ich in Trainings genauso zum Besten gebe: Es musste wohl schnell gehen. Freitagmittag, das Essen stand schon auf dem Tisch - “na gut, dann nehmen wir halt Secret”, sei’s drum. Eindeutig und zielführend war das jedenfalls nicht.

Und genau deshalb geht, nach meiner Erfahrung, so gut wie jeder Teilnehmer bis zu diesem Moment im Training ganz selbstverständlich davon aus, dass Secrets sicher sind - der Name legt’s ja nahe. “Secret” klingt nach Tresor. Ist aber eine Postkarte: jeder, der sie in die Hand kriegt, liest einfach mit. Kein Umschlag, kein Schloss, nichts. Base64 ist keine Geheimschrift, das ist Spiegelschrift: sieht kurz komisch aus, ist aber in zwei Sekunden entziffert. Die Anschlussfrage kommt danach fast automatisch: “Und wie macht man es dann richtig?” Genau die habe ich mir mal als Cliffhanger für den nächsten Trainingstag aufgehoben. Hier bekommst du die Antwort direkt.

Wenn ich weitererzähle, wird’s meistens noch stiller

Denn Kubernetes hat einen großen, persistenten Speicher im Keller, der nennt sich etcd - ein Key-Value-Store -, und da landet alles, auch deine Secrets. Von Werk aus steht dieser Speicher offen. Wer mal kurz in den Keller kommt - ein gekaperter Node, ein altes Backup, ein Snapshot, völlig egal wie - greift direkt rein, komplett an Kubernetes-API und RBAC vorbei. Den Riegel musst du selbst vorschieben, über eine EncryptionConfiguration am API-Server. Von Haus aus ist der Keller offen.

Zwei Sätze, die ich ständig höre - und beide Male widerspreche

“Wir haben doch RBAC.” Das höre ich in praktisch jedem Firmentraining. RBAC ist dein Türsteher, der checkt die Gästeliste. Aber wenn drinnen die Kasse offen auf dem Tresen steht, hilft dir der beste Türsteher nichts - wer reindarf, liest den Klartext sofort mit.

“Für unser kleines Projekt reicht das.” Eine offene Kasse ist eine offene Kasse, egal ob im Kiosk oder im Kaufhaus. Ein Datenbank-Passwort in einem Zwei-Personen-Projekt ist genauso lesbar wie eine API-Key-Sammlung im Konzern.

Was ich Teilnehmern als nächsten Schritt zeige

Also, wie kriegst du die Postkarte in einen Umschlag? Den ersten Griff, den ich zeige, ist Sealed Secrets: ein Vorhängeschloss, für das nur dein eigener Cluster den Schlüssel hat. Simpel, in einer halben Stunde eingerichtet, reicht für den ersten Cluster locker. Willst du den Schlüssel nicht an die Cluster-Tür hängen, sondern lieber extern lagern, zeige ich SOPS, mein Standardtipp für GitOps mit Flux. Und dann gibt’s die Profi-Liga, External Secrets Operator: Da schreibst du gar nichts mehr auf die Postkarte, sondern nur noch einen Zettel mit “frag bei der Bank nach”. Der Wert liegt im Hochsicherheitstrakt eines echten Secrets-Managers wie OpenBao - im Cluster steht nur die Referenz darauf, der Operator holt sich zur Laufzeit genau die Credentials, für die er berechtigt ist. Mehr Aufwand beim Aufsetzen - aber die sauberste Lösung, sobald mehrere Cluster dieselbe Bank nutzen sollen.

Meine klare Ansage

Ganz ehrlich: Bastelst du allein, nimm SOPS oder Sealed Secrets und gut ist - beide verhindern, dass das im Klartext in deiner Versionsverwaltung (i.d.R. Git) auftaucht, ohne dass du gleich eine zusätzliche Infrastruktur-Komponente betreiben musst. Sobald aber mehr als ein Cluster oder mehr als ein Team am Start ist, führt kein Weg am External Secrets Operator vorbei. Ganz einfach: Wenn ein Passwort kompromittiert ist, willst du nicht nachts durch ein Dutzend verstreute Manifeste jagen. Du willst den Wert an einer einzigen zentralen Stelle austauschen. Fertig.

Fazit

Secret steht drauf - sicher ist es deswegen noch lange nicht. Genau deshalb baue ich diesen Moment bewusst live in mein Training “Kubernetes Einführung” ein, statt ihn nur auf einer Folie zu erklären: Secret anlegen, dekodieren, erschrecken. Was einmal wehgetan hat, bleibt sicherer im Kopf hängen als jede Theorie - das gilt für Secrets genauso wie für jedes andere Missverständnis, das ich in zehn Jahren Training gesehen habe.