Zero Trust für Internal Developer Platforms

Lernziele

Nach dieser Lektion kannst du erklären, warum das Perimeter-Modell in einer Multi-Tenant-Plattform versagt und was Zero Trust stattdessen fordert: Identität statt Netzwerkposition, mTLS überall, Least Privilege und kurzlebige Credentials. Du kennst die konkreten Bausteine — Workload-Identität nach SPIFFE-Muster, Service Mesh, Default-Deny-NetworkPolicies — und kannst die Betriebskosten dieses Modells ehrlich gegen seinen Nutzen abwägen.

Das Problem: Das Cluster-Netz ist flach und jeder ist drin

Das klassische Sicherheitsmodell ist eine Burg: harte Schale (Firewall, VPN), weiches Inneres. Innerhalb des Perimeters gilt Vertrauen. Für eine Kubernetes-Plattform ist dieses Modell aus zwei Gründen wertlos.

Erstens: Ein Cluster-Netz ist per Default flach. Ohne NetworkPolicies kann jeder Pod jeden anderen Pod erreichen — der Experimentier-Container von Team A spricht ungehindert mit der Produktions-Datenbank von Team B. In einer Plattform mit 50 Mandanten heißt das: Eine einzige kompromittierte Anwendung (eine verwundbare Dependency reicht, dazu mehr in Lektion 44) gibt dem Angreifer ein Sprungbrett ins gesamte Innere. Genau das ist Lateral Movement, und das flache Netz ist seine Autobahn.

Zweitens: Der „Perimeter” existiert ohnehin nicht mehr. Entwickler greifen von überall zu, CI-Systeme deployen aus der Cloud, die Plattform spricht mit Managed Services außerhalb des Clusters. Eine geklaute kubeconfig oder ein geleaktes CI-Token wirken von jedem Café-WLAN der Welt.

Zero Trust zieht daraus die Konsequenz: Netzwerkposition ist kein Vertrauensbeweis. Jede Verbindung — Mensch zu Plattform, Service zu Service, Pipeline zu Cluster — wird authentifiziert, autorisiert und verschlüsselt, jedes Mal. Und das Design geht von Assume Breach aus: Es fragt nicht „wie halten wir Angreifer draußen?”, sondern „wie klein bleibt der Schaden, wenn einer drin ist?”

Identität für Workloads: das Ende der mitgeschleppten Secrets

Der Kern von Zero Trust ist nicht Verschlüsselung, sondern Identität. Für Menschen ist das gelöst: OIDC gegen den zentralen IdP, Gruppen aus dem Verzeichnis, kurzlebige Tokens statt statischer kubeconfigs — das Fundament aus Lektion 34. Die härtere Frage: Woher bekommt ein Workload seine Identität?

Die schlechte Antwort ist die verbreitetste: ein API-Key im Secret, ins Deployment gemountet, nie rotiert. Solche Credentials sind langlebig, kopierbar und tauchen in Logs, Backups und Git-Historien auf. Die Zero-Trust-Antwort: Die Plattform attestiert, was ein Workload ist, und stellt ihm daraus eine kurzlebige, überprüfbare Identität aus. Kubernetes bringt den Mechanismus mit — ServiceAccount-Tokens, die der API-Server als zeitlich begrenzte, audience-gebundene JWTs ausstellt. Cloud-Provider akzeptieren sie via OIDC-Federation als Login (Workload Identity), womit Cloud-Zugriffe ganz ohne gespeicherte Keys funktionieren.

Das verallgemeinerte Muster heißt SPIFFE: Jeder Workload bekommt eine eindeutige Identität (spiffe://trust-domain/ns/team-a/sa/checkout), ausgestellt als kurzlebiges X.509-Zertifikat oder JWT, automatisch rotiert. Implementierungen wie SPIRE oder die Identitätsschicht eines Service Mesh übernehmen Ausstellung und Rotation. Der Effekt für die Plattform: Es gibt nichts Langlebiges mehr zu stehlen — ein erbeutetes Zertifikat ist nach Minuten wertlos.

mTLS überall — und wer es liefern soll

mTLS (mutual TLS) heißt: Beide Seiten einer Verbindung weisen sich mit Zertifikaten aus. Das liefert drei Dinge auf einmal — Verschlüsselung, Authentifizierung des Servers und des Clients. Erst mit mTLS kannst du Autorisierungsregeln auf Identitäten statt auf IP-Adressen schreiben: „checkout darf payment aufrufen, sonst niemand” — IPs sind in Kubernetes ohnehin flüchtig.

Die Frage ist nicht ob, sondern wo implementiert. Drei realistische Optionen:

• Service Mesh (Istio, Linkerd): Sidecar- oder Node-Proxies übernehmen mTLS, Identitäten und Autorisierungs-Policies transparent — Anwendungen bleiben unverändert. Der Preis: eine weitere Plattform-Komponente mit eigener Upgrade-Kadenz, eigenem Failure-Modus (was passiert bei Proxy-Crash?) und echter Lernkurve. Ein Mesh ist ein Betriebs-Commitment, kein Featureflag.
• CNI mit Verschlüsselung und identitätsbasierten Policies (z. B. Cilium mit WireGuard-Verschlüsselung): weniger Moving Parts als ein Mesh, dafür weniger Layer-7-Ausdrucksstärke bei Autorisierung.
• In der Anwendung: maximale Kontrolle, aber 50 Teams implementieren TLS-Handling 50-mal — für eine Plattform fast immer die falsche Wahl, weil sie genau die Arbeit dupliziert, die die Plattform wegnehmen soll.

Die ehrliche Empfehlung hängt am Bedarf: Wer nur Verschlüsselung und L3/L4-Segmentierung braucht, fährt mit CNI-Mitteln schlanker. Wer identitätsbasierte L7-Autorisierung und feingranulare Traffic-Kontrolle braucht, landet beim Mesh — und sollte die Betriebskosten laut aussprechen, bevor er sie trägt.

Dritter Baustein neben Identität und mTLS: Default Deny. NetworkPolicies (Lektion 22) so, dass nichts erlaubt ist, was nicht deklariert wurde — von der Plattform pro Namespace vorprovisioniert, nicht den Teams als Hausaufgabe überlassen. Erlaubte Verbindungen deklarieren die Teams in ihren Manifesten; die Plattform validiert sie per Policy-as-Code (Lektion 28).

Least Privilege ohne Entwickler-Aufstand

Zero Trust scheitert in der Praxis selten an der Technik, sondern an der Friction: Wenn jeder Datenbankzugriff drei Genehmigungen braucht, bauen sich Teams Hintertüren. Die Plattform-Antwort ist, Least Privilege in die Golden Paths einzubacken, statt ihn zu verordnen: Das Standard-Chart erzeugt einen dedizierten ServiceAccount pro Workload (statt default), automountServiceAccountToken: false wo kein API-Zugriff nötig ist, NetworkPolicy-Gerüst inklusive, Cloud-Zugriff via Workload Identity vorverdrahtet. Wer den Golden Path nutzt, ist sicher, ohne es zu merken — Security by Default statt Security by Disziplin.

Für menschliche Zugriffe gilt dasselbe Prinzip in Zeitform: Stehende Admin-Rechte werden durch Just-in-Time-Zugriff ersetzt — angefordert, begründet, zeitlich begrenzt, protokolliert. Wie das organisatorisch sauber läuft (Break-Glass, Access Reviews), ist Thema von Lektion 45.

Praxis

Mache das flache Netz einmal sichtbar und schließe es dann — im Lab-Cluster mit installiertem NetworkPolicy-fähigem CNI:

kubectl create ns team-a; kubectl create ns team-b
kubectl -n team-b create deploy web --image=nginx
kubectl -n team-b expose deploy web --port=80

# Beweis des Problems: Cross-Namespace-Zugriff funktioniert einfach so
kubectl -n team-a run probe --rm -it --image=busybox --restart=Never \
  -- wget -qO- --timeout=2 web.team-b.svc.cluster.local

Lege dann eine Default-Deny-Policy in team-b an:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: team-b
spec:
  podSelector: {}
  policyTypes: ["Ingress"]

Wiederhole den wget — er muss jetzt in den Timeout laufen. Erlaube anschließend gezielt Traffic aus team-a per zweiter Policy mit namespaceSelector und prüfe erneut. Notiere dir den Dreischritt (offen → zu → gezielt offen): Genau diese Demo trägt auch im Interview.

Typische Stolperfallen

Zero Trust als Produktkauf: Ein Mesh installieren und „Zero Trust: done” deklarieren, während CI-Tokens ewig leben und Admins stehende cluster-admin-Rechte haben. Zero Trust ist ein Architekturprinzip über alle Zugriffspfade, kein Add-on.

mTLS im Permissive-Modus vergessen: Meshes starten oft tolerant (Klartext erlaubt), damit die Migration nicht bricht. Wer den Schalter auf strict nie umlegt, hat Verschlüsselungs-Theater.

Default Deny ohne Vorwarnung ausrollen: Über Nacht aktiviert, legt es jede nicht deklarierte (aber legitime) Verbindung lahm. Erst beobachten (Flow-Logs), dann Policies generieren, dann enforcen — derselbe Audit-vor-Enforce-Ablauf wie bei Admission-Policies.

Zertifikatsrotation als unsichtbarer Single Point of Failure: Wenn die Ausstellungskette (CA, Issuer, Mesh-Control-Plane) ausfällt, laufen Workloads weiter — bis die ersten Zertifikate ablaufen und der Cluster scheibchenweise stirbt. Die Ausstellungs-Infrastruktur braucht eigene SLOs und Alerts.

Interview-Vorbereitung

Die Standardfrage „Wie setzt du Zero Trust auf einer internen Plattform um?” beantwortest du problem-first: Warum (flaches Cluster-Netz, Lateral Movement, gestohlene langlebige Credentials) → Prinzip (Identität statt Netzwerkposition, jede Verbindung authentifiziert und autorisiert, Assume Breach) → Bausteine (Workload-Identität mit kurzlebigen Tokens/Zertifikaten, mTLS via Mesh oder CNI, Default-Deny-Policies, JIT statt stehender Rechte) → Plattform-Dreh (alles in Golden Paths einbacken, damit der sichere Weg der bequeme ist).

Typische Follow-ups:

• „Woher bekommt ein Pod seine Identität?” — Projizierte ServiceAccount-Tokens (kurzlebig, audience-gebunden), via OIDC-Federation auch für Cloud-Zugriffe; verallgemeinert im SPIFFE-Muster mit automatischer Rotation.
• „Brauche ich dafür zwingend ein Service Mesh?” — Nein: Verschlüsselung und L3/L4-Segmentierung gehen auch auf CNI-Ebene; das Mesh lohnt erst für identitätsbasierte L7-Autorisierung — gegen reale Betriebskosten.
• „Was bedeutet Assume Breach konkret im Design?” — Blast Radius pro Workload minimieren: Segmentierung, Least Privilege, kurzlebige Credentials, Audit-Trail; nicht primär in höhere Mauern investieren.
• „Wie verkaufst du das den Entwicklern?” — Gar nicht als Security-Auflage, sondern als Default im Golden Path: dedizierter ServiceAccount, Policies und Workload Identity kommen aus dem Template mit.

Zusammenfassung

Zero Trust ersetzt das Burg-Modell durch ein einfaches Prinzip: Kein Akteur ist vertrauenswürdig, weil er im richtigen Netz steht. Die Plattform setzt das um mit Workload-Identitäten und kurzlebigen Credentials statt mitgeschleppter Secrets, mTLS für jede Verbindung (Mesh oder CNI — bewusst gewählt), Default-Deny-Segmentierung und Least Privilege, das über Golden Paths zum bequemen Standard wird. Assume Breach heißt: Der Maßstab ist der Schaden nach dem Einbruch, nicht die Höhe der Mauer.

Die nächste Lektion hebt das auf die regulatorische Ebene: Compliance-by-Design — wie SOC2, ISO 27001 und BSI-Anforderungen zu Plattform-Eigenschaften werden statt zu jährlichen Audit-Feuerwehrübungen.