Begriff

Secret (K8s)

Kubernetes Security S1

2 Quellen 1 Lernpfad 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Ein Passwort gehört nicht in den Code. Und auch nicht in eine ConfigMap (die ist offen lesbar). Kubernetes hat dafür Secrets. Es ist ein spezielles Objekt für sensible Daten (DB-Passwort, API-Token, SSL-Key). Du kannst es als Datei in den Pod mounten (/etc/secrets/db-pass) oder als Variable (DB_PASS) nutzen. Der Clou: Kubernetes stellt sicher, dass Secrets nicht versehentlich in Logs oder kubectl describe auftauchen (eingeschränkt).

Merksatz: Ein Kubernetes-Objekt zur Speicherung und Verwaltung sensibler Informationen wie Passwörter, OAuth-Token und SSH-Schlüssel, getrennt vom Pod-Code.

Erstellen: kubectl create secret generic my-pass --from-literal=password=Geheim123 In YAML sieht es verschlüsselt aus?

data:
  password: R2uheimMTIz

Nein! Das ist nur Base64. Jeder kann echo R2uheimMTIz | base64 -d machen und "Geheim123" lesen. Secrets sind standardmäßig nicht verschlüsselt, nur obfuskiert ("versteckt"). Wer Zugriff auf den Namespace hat, kann Secrets lesen.

Praxisroutine

In der Praxis lernst du Secret (K8s), indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Encryption at Rest (Etcd)

Secrets liegen in der etcd Datenbank des Clusters. Standardmäßig liegen sie dort im Klartext! Wenn ein Hacker die Festplatte vom Master-Node klaut, hat er alle Passwörter. Profis aktivieren Encryption at Rest. Der API-Server verschlüsselt das Secret (AES-CBC), bevor er es in etcd schreibt. Key-Management (KMS) ist hier wichtig (z. B. AWS KMS Plugin).

2. External Secrets Operator (ESO)

In GitOps darfst du keine Secrets (auch kein Base64!) ins Git committen. Lösung: External Secrets. Du legst das echte Passwort in AWS Secrets Manager, Azure KeyVault oder HashiCorp Vault. Im Cluster läuft der ESO. Er holt das Passwort aus dem Vault und erstellt ein lokales K8s Secret (temporär). Vorteil: Single Source of Truth, Audit Logs im Vault, und kein Secret im Git.

3. Immutable Secrets

Wenn eine App startet, liest sie das Secret. Wenn du das Secret änderst ("Rotate Password")... merkt die App das? Meistens Nein (Env Vars werden nur beim Start gesetzt). Gemountete Files (volumeMount) werden eventuell aktualisiert (nach Minuten). Sicherer Weg: Immutable Secrets. Setze immutable: true. K8s verbietet Updates. Wenn du rotieren willst, erstelle secret-v2 und deploye die App neu. Das verhindert Inkonsistenzen.

1. Service Account Token Volume Projection

Früher (vor K8s 1.21) war das Standard-Token für Kubernetes Prozesse ein einfaches Secret, das ewig gültig war. Das war ein Sicherheitsrisiko. Heute wird das Service Account Token nicht mehr als statisches Secret, sondern via Bound Service Account Token Volumes injiziert. Kubernetes nutzt intern den kube-apiserver, um zeitlich begrenzte JWTs zu generieren, die direkt in den RAM des Pods gemountet werden. Diese Token laufen nach 1 Stunde ab und werden automatisch "rotiert". Stirbt der Pod, ist das Token sofort ungültig. Das verhindert, dass ein gestohlenes Token Tage später noch Zugriff auf die API erlaubt.

2. RBAC & Secret-Leaking Gefahren

Ein häufiger Fehler im Least Privilege Design: Ein Service (z.B. ein Backup-Skript) bekommt die Berechtigung get secrets. Das Problem: In K8s ist get secret ein binäres Alles-oder-Nichts. Du kannst (ohne Zusatztools) kaum sagen: "Darf nur Secret A lesen, aber nicht Secret B". Wer get secrets darf, kann auch das Secret des Cluster-Admins oder die Cloud-Zugangsdaten anderer Apps dumpen. Lösung: Resource Names in RBAC-Rollen nutzen, um den Zugriff explizit auf bestimmte IDs einzuschränken, oder Tools wie Kyverno nutzen, um den Zugriff feingranularer zu policen.

3. Sidecar-Injection für dynamische Secrets

Bei Hochsicherheits-Systemen will man gar keine K8s-Secrets mehr nutzen (wegen der etcd Problematik). Man nutzt die Agent Sidecar Injection von HashiCorp Vault. Dabei wird beim Start des Pods automatisch ein kleiner Container (Sidecar) hinzugefügt. Dieser authentifiziert sich beim externen Vault, holt die Secrets und schreibt sie in ein gemeinsames emptyDir Volume (RAM-Disk). Deine App liest dann einfach eine Datei /secrets/config.json. Das K8s Master-System (Etcd) sieht diese Daten niemals. Es sind flüchtige Secrets, die nur im RAM des spezifischen Pods existieren.

Quick-Check

tmpfs?
Secrets, die als Datei gemountet werden, liegen nie auf der Node-Festplatte. Sie liegen im RAM (tmpfs). Wenn der Strom ausfällt, sind sie weg. Das schützt vor Festplatten-Forensik.
Environment vs Volume?
Env Var ist unsicherer. Wenn der Prozess crasht, steht das ganze Environment (inkl. Passwort) oft im Crash Dump Log. Files sind sicherer.
bitnami-sealed-secrets?
Eine Alternative zu ESO. Du verschlüsselst das Secret lokal mit dem Public Key des Clusters. Das Ergebnis ("SealedSecret") darf ins Git. Nur der Controller im Cluster (Private Key) kann es entschlüsseln. Einfacher als Vault.