Kubernetes-Secrets: External oder Sealed Secrets?
Kubernetes-Secrets sind nur Base64, nicht verschlüsselt. Wie External Secrets und Sealed Secrets Geheimnisse aus dem Klartext und sicher aus Git halten.
Ein Kubernetes-Secret speichert sensible Werte im Auslieferungszustand nur als Base64-kodierten Text. Wer die Werte kennt, liest sie in Sekunden im Klartext. Richtig gefährlich wird es, wenn diese Secrets im Git-Repository landen, wo sie für immer in der Historie stehen. Zwei etablierte Verfahren bringen Geheimnisse aus dem Klartext heraus, ohne den GitOps-Workflow aufzugeben. Die Entscheidung hängt davon ab, wo die Quelle der Wahrheit liegen soll.
Das Wichtigste in Kürze
- Base64 ist keine Verschlüsselung: Kubernetes-Secrets liegen standardmäßig nur kodiert in etcd. Wer Zugriff auf etcd oder die API hat, liest sie im Klartext. Schutz entsteht erst durch Verschlüsselung im Ruhezustand und saubere API-Rechte.
- Klartext in Git ist der teure Fehler: Ein einmal committetes Geheimnis bleibt in der Historie. Allein 2025 fand GitGuardian 28,65 Millionen hartkodierte Secrets in öffentlichen Repositories, ein Drittel mehr als im Jahr davor.
- Quelle der Wahrheit entscheidet: External Secrets holt Geheimnisse aus einem externen Tresor, Sealed Secrets verschlüsselt sie für Git. Die Wahl hängt davon ab, welches System das Secret verwaltet.
Verwandt:Cloud-native reift mit Kubernetes 1.34 / OpenTofu vs. Terraform
Warum ein Kubernetes-Secret kein Geheimnis ist
Was ist ein Kubernetes-Secret? Ein Kubernetes-Secret ist ein Objekt, das sensible Daten wie Passwörter, Tokens oder Schlüssel von der Anwendungskonfiguration trennt. Die Werte werden standardmäßig Base64-kodiert im zentralen Speicher etcd abgelegt. Base64 ist eine Kodierung, keine Verschlüsselung, das Secret ist also für jeden mit Zugriff auf etcd oder die API im Klartext lesbar.
Genau dort beginnt das Betriebsrisiko. Viele Teams behandeln das Secret-Objekt als geschützt, weil der Wert nicht sofort lesbar aussieht. Tatsächlich ist die Kodierung nur eine Transportform. Ohne zusätzliche Maßnahmen liegt das Geheimnis offen: in etcd, in jedem API-Antwortobjekt und in jedem Backup des Clusters, das den Zustand mitschreibt.
Die erste Verteidigungslinie ist deshalb die Verschlüsselung von etcd selbst, kombiniert mit strengen Zugriffsrechten auf die API. Das schützt das Secret im Ruhezustand. Es löst aber nicht das zweite, größere Problem: den Weg des Geheimnisses in die Konfiguration. Dort entsteht der eigentliche Betriebsfehler.
Wenn Klartext in Git landet
GitOps verlagert Konfiguration bewusst ins Repository. Das Secret mitzuschreiben ist der eigentliche Fehler. Ein einmal committetes Geheimnis bleibt in der Historie, selbst wenn die nächste Änderung es wieder entfernt. Wer den Schlüssel rotiert, hat das alte Geheimnis nicht beseitigt, sondern nur ein zweites hinzugefügt.
Diese öffentliche Zahl unterschätzt das interne Risiko. Interne Repositories enthalten nach denselben Analysen rund sechsmal häufiger hartkodierte Geheimnisse als öffentliche, weil der Eindruck von Abgeschlossenheit die Sorgfalt senkt. Das Risiko verschwindet nicht mit der Zeit: Ein erheblicher Teil der vor Jahren geleakten und weiter gültigen Secrets ist bis heute nutzbar. Ein Geheimnis im Git-Verlauf bleibt ein offenes Risiko, solange es gültig ist.
Zwei Wege raus: External Secrets und Sealed Secrets
Beide Verfahren lösen dasselbe Problem, greifen aber an unterschiedlichen Punkten des Workflows ein. Der External Secrets Operator hält das Geheimnis außerhalb des Clusters und holt es bei Bedarf. Sealed Secrets verschlüsselt das Geheimnis so, dass im Repository kein Klartext liegt. Entscheidend ist, welches System das Secret führen soll.
| Kriterium | External Secrets Operator | Sealed Secrets |
|---|---|---|
| Quelle der Wahrheit | externer Tresor | das Git-Repository |
| Was liegt in Git | nur ein Verweis | verschlüsseltes Secret |
| Rotation | zentral im Tresor, automatisch | erneut verschlüsseln und committen |
| Abhängigkeit | externer Dienst muss erreichbar sein | Controller-Schlüssel im Cluster |
| Passt zu | vorhandener Vault, viele Cluster | reine GitOps ohne externen Tresor |
Für Teams mit zentralem Tresor wie HashiCorp Vault oder einem Cloud-Secret-Manager ist der External Secrets Operator meist die bessere Wahl. Das Geheimnis bleibt an einem Ort, die Rotation läuft dort, Kubernetes erhält nur eine temporäre Kopie. Wer ohne externen Dienst auskommen und alles im Repository halten will, ist mit Sealed Secrets richtig, muss aber den Controller-Schlüssel im Cluster sichern und rotieren. Auch die Werkzeuge selbst brauchen Pflege: Eine 2026 gemeldete Schwachstelle in Sealed Secrets zeigt, dass selbst der Schutzmechanismus ein Patch-Ziel ist.
Was sicheres Secret-Management trägt und was es untergräbt
Ob ein Verfahren wirklich schützt oder nur ein gutes Gefühl liefert, entscheidet die Umsetzung im Detail. Die folgenden Muster trennen das eine vom anderen.
Was untergräbt
- Das Base64-Secret für geschützt halten, etcd unverschlüsselt lassen
- Geheimnisse einmal committen und auf späteres Entfernen vertrauen
- Langlebige Schlüssel ohne Rotation und ohne Ablaufdatum
- Den Controller- oder Tresor-Zugang so breit wie den normalen Cluster
Was trägt
- etcd verschlüsseln und API-Zugriff streng begrenzen
- Geheimnisse nie im Klartext committen, ein Verfahren konsequent nutzen
- Kurze Gültigkeit und automatische Rotation als Standard
- Tresor- und Controller-Schlüssel getrennt und eng berechtigt halten
Der gemeinsame Nenner ist eine schlichte Haltung: Ein Geheimnis ist nur so sicher wie sein am schlechtesten geschützter Ort. Base64 zu durchschauen, etcd zu verschlüsseln und ein Verfahren konsequent durchzuziehen, ist weniger Aufwand als die Bereinigung nach einem geleakten Schlüssel. Die Werkzeuge sind reif und kostenlos verfügbar. Was fehlt, ist meist nur die Entscheidung, das Geheimnis ernster zu nehmen als seine Kodierung.
Häufige Fragen
Sind Kubernetes-Secrets verschlüsselt?
Standardmäßig nicht. Die Werte werden Base64-kodiert in etcd gespeichert, und Base64 ist eine Kodierung, keine Verschlüsselung. Wer Zugriff auf etcd oder die API hat, liest sie im Klartext. Echte Verschlüsselung im Ruhezustand muss für etcd separat aktiviert werden, zusammen mit strengen Zugriffsrechten.
Was macht der External Secrets Operator?
Er liest Geheimnisse aus einem externen Tresor wie HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault und erzeugt daraus automatisch native Kubernetes-Secrets. Die Quelle der Wahrheit bleibt im Tresor, im Cluster liegt nur eine synchronisierte Kopie. Im Repository steht lediglich ein Verweis, nie das Geheimnis selbst.
Wie funktionieren Sealed Secrets?
Ein Geheimnis wird mit einem öffentlichen Schlüssel verschlüsselt, den nur ein Controller im Cluster entschlüsseln kann. Das verschlüsselte Objekt lässt sich gefahrlos ins Git-Repository committen. Der Controller entschlüsselt es beim Anwenden im Cluster zu einem normalen Secret. So bleibt echtes GitOps möglich, ohne ein Geheimnis im Klartext abzulegen.
Welches Verfahren ist das richtige?
Das hängt davon ab, wo die Quelle der Wahrheit liegen soll. Gibt es bereits einen zentralen Tresor und viele Cluster, passt der External Secrets Operator. Soll alles im Repository bleiben und kein externer Dienst nötig sein, sind Sealed Secrets der einfachere Weg. Beide sind etabliert, der Unterschied ist der Ort des Geheimnisses.
Was passiert mit Secrets, die schon in Git stehen?
Sie gelten als kompromittiert und müssen rotiert werden, nicht nur entfernt. Das Entfernen aus der aktuellen Version lässt das Geheimnis in der Historie zurück. Der einzige sichere Weg ist, den betroffenen Schlüssel oder das Passwort ungültig zu machen und neu auszustellen, danach das Verfahren auf einen der beiden sauberen Wege umzustellen.
Bildquelle: Titelbild KI-generiert (Juni 2026), C2PA-Zertifikat im Bild hinterlegt
