Case: Zero Trust Platform

Lernziele

Nach dieser Lektion kannst du den Case „Zero Trust für die Internal Developer Platform” im Interview durchspielen: Du erklärst, warum „im internen Netzwerk sind wir sicher” in Platform-Umgebungen nicht gilt, kannst Default-Deny-Netzwerk, identity-basierten Zugriff und mTLS begründet kombinieren, hast Antworten auf Developer-Friction-Einwände parat und kennst einen phasenweisen Rollout ohne Big-Bang-Ausfall.

Das Szenario

Die Aufgabe: „Designe eine Zero-Trust-Architektur für unsere Internal Developer Platform. 60 Teams auf gemeinsamen Kubernetes-Clustern. Kein implizites Vertrauen im Netzwerk — jeder Zugriff muss authentifiziert und autorisiert sein.” Der Case ist beliebt, weil er zwei Welten kollidieren lässt: Security will Default Deny und Verschlüsselung überall, Entwickler wollen kubectl port-forward und schnelle Iteration. Wer nur Buzzwords stapelt, scheitert — wer Zero Trust als Schichtenmodell erklärt, punktet.

Anforderungen klären: Vertrauensgrenzen definieren

Diese fünf Fragen legen fest, wie tief Zero Trust geht:

• „Welche Assets schützen wir — nur Workloads oder auch Entwickler-Zugriffe?” — Angenommen: beides. Services im Cluster und Developer-Zugriff auf APIs, Dashboards und kubectl.
• „Gibt es Legacy-Systeme, die kein mTLS sprechen?” — Angenommen: 90 % Kubernetes-native, wenige VMs mit IP-basiertem Zugriff als Übergang. Das erlaubt einen Migrationspfad statt Alles-oder-Nichts.
• „Welche Compliance-Anforderungen?” — Angenommen: Audit-Log aller Zugriffe, Verschlüsselung in Transit, least-privilege RBAC. Kein explizites Mandat für Hardware-HSM, aber dokumentierter Break-Glass.
• „Wie authentifizieren sich Entwickler heute?” — Angenommen: SSO via OIDC (Okta), Gruppen-Mapping auf Teams. Zero Trust baut darauf auf, ersetzt es nicht.
• „Was ist akzeptable Latenz und Komplexität?” — Sidecar-basiertes mTLS auf L7 ist mächtig, aber operativ aufwändig. Die Frage zwingt dich, L3/L4 vs. L7 zu begründen.

Fasse zusammen: „Default-Deny-Netzwerk, identity-basierter Zugriff statt IP-Listen, mTLS zwischen Services, SSO für Entwickler, alles auditierbar — einverstanden?”

Architektur: Zero Trust als Schichtenmodell

Zero Trust ist kein Produkt, sondern ein Prinzip: Nie vertrauen, immer verifizieren. In der Praxis vier Schichten:

1. Netzwerk — Default Deny. Cilium mit eBPF-basierten NetworkPolicies: Jeder Namespace startet mit deny-all. Erlaubte Verbindungen werden deklarativ freigegeben — Team-Checkout darf nur Team-Payment und die Shared-DB erreichen, nicht Team-HR. Cilium Hubble liefert Flow-Logs für Audit und Debugging.

2. Verschlüsselung — mTLS everywhere. Zwei Wege, die du im Interview gegeneinander abwägen musst: Cilium mit WireGuard verschlüsselt auf L3/L4 — transparent für die Anwendung, geringerer Overhead. Istio/Linkerd macht mTLS auf L7 mit feineren Routing-Regeln, aber Sidecar-Komplexität. Empfehlung im Case: Cilium WireGuard als Baseline, Service Mesh nur für Teams, die L7-Traffic-Management brauchen.

3. Identity — Zugriff an Identität binden. Kubernetes RBAC least-privilege pro Team-Namespace. Entwickler-Zugriff auf kubectl über OIDC-Impersonation: SSO-Login, Token mit Gruppen-Claim, RBAC mappt Gruppe auf Namespace-Rolle. Keine statischen kubeconfig mit cluster-admin. Für APIs (Backstage, Argo CD, Grafana): OIDC-Proxy oder native OIDC-Integration, Rollen aus Gruppen.

4. Observability und Break-Glass. Kubernetes Audit Logs plus Hubble-Flows in zentrales SIEM. Break-Glass-Account existiert, ist dokumentiert, alarmiert bei Nutzung und wird nach Incident rotiert. Zero Trust ohne Notfallpfad ist Zero Availability.

Einwände des Interviewers

„Entwickler beschweren sich — alles ist langsam und kompliziert.” Gegenargument mit Maßnahmen: NetworkPolicies als Code im Tenants-Repo, generiert von Kyverno beim Namespace-Anlegen — Entwickler müssen keine Policies selbst schreiben. Staging-Umgebung mit gelockerten Regeln für Experimente. Onboarding-Docs mit „welche Verbindung du brauchst und wie du sie beantragst.”

„Cilium oder Istio — nicht beides?” Richtig — Overlap vermeiden. Cilium für Netzwerk und L3/L4-Verschlüsselung, Istio nur wo L7 nötig. Wer beides vollständig stapelt, hat doppelte Sidecars und doppelten Betriebsaufwand.

„Ein kompromittierter Pod im Namespace — hilft Default Deny?” Ja, gegen laterale Bewegung: Der Pod erreicht nur explizit erlaubte Ziele. Nein, gegen Exfiltration über erlaubte Verbindungen — deshalb egress-Policies und egress-Gateway für kontrollierten Internetzugang.

„Wie rollst du das aus, ohne 60 Teams gleichzeitig zu blockieren?” Audit-Modus zuerst: Policies im Log-only-Modus, Violations sammeln, Teams informieren. Dann Enforce namespace für namespace. Nie Big Bang.

Praxis

Spiele den Case 45 Minuten am Whiteboard. Diese fünf Punkte müssen vorkommen:

1. Fünf Klärungsfragen inklusive Legacy und Developer-Friction.
2. Das Vier-Schichten-Modell: Netzwerk, Verschlüsselung, Identity, Audit.
3. Begründete Wahl Cilium WireGuard vs. Istio mTLS — nicht beides vollständig.
4. Developer-Zugriffspfad: SSO → OIDC → RBAC/Impersonation.
5. Phasen-Rollout: Audit → Enforce pro Namespace → Break-Glass dokumentiert.

Variiere beim zweiten Durchlauf: „Ein Team braucht Zugriff auf ein externes SaaS-API — wie sieht egress aus?”

Typische Stolperfallen

Zero Trust mit „VPN abschalten” gleichsetzen. VPN ist ein Zugangskanal; Zero Trust definiert, was nach dem Zugang erlaubt ist. Beides kann koexistieren.

Nur mTLS nennen, NetworkPolicy vergessen. Verschlüsselung schützt Inhalte, nicht vor unautorisierten Verbindungen. Beides gehört zusammen.

Break-Glass ignorieren. Ohne dokumentierten Notfallzugang blockiert Zero Trust das Plattform-Team im Incident — und Security verliert das Vertrauen.

IP-basierte Regeln als Zero Trust verkaufen. „Nur aus dem Büro-Netz” ist das Gegenteil von identity-basiertem Zugriff.

Interview-Vorbereitung

Deine Kernbotschaft: Zero Trust als Schichten — Default Deny mit Cilium, Verschlüsselung mit WireGuard, Identity über OIDC und RBAC, Audit über Hubble und Kubernetes Audit Logs — phasenweise eingeführt, mit Break-Glass.

Rechne mit diesen Follow-ups:

• „Wie debuggt ein Entwickler eine blockierte Verbindung?” — Hubble UI/CLI zeigt dropped Flows, Policy-Name steht im Event.
• „Was ändert sich bei 200 Teams?” — Policy-Templates statt Einzelpolicies, zentrale Policy-Bibliothek im Git, automatische Generierung beim Onboarding.
• „Zero Trust vs. Perimeter Security?” — Perimeter schützt die Grenze; Zero Trust geht davon aus, dass die Grenze bereits durchbrochen ist.

Zusammenfassung

Der Zero-Trust-Case prüft Schichten-Denken: Default-Deny-Netzwerk, Verschlüsselung in Transit, identity-basierter Zugriff statt IP-Vertrauen, Audit und Break-Glass als Ergänzung. Cilium für Netzwerk und L3/L4, Service Mesh nur bei L7-Bedarf. Rollout im Audit-Modus, Enforcement schrittweise — Geschwindigkeit und Security über Automatisierung und Golden Paths, nicht über Ausnahmen. In der nächsten Lektion hebst du die Perspektive auf die Cloud-Ebene: eine AWS Landing Zone, die Teams mit Guardrails statt mit Blanko-Accounts versorgt.