Case: Policy-as-Code Platform

Lernziele

Nach dieser Lektion kannst du den Case „Policy-as-Code-Plattform für 80 Teams” im Interview durchspielen: Du weißt, welche Rückfragen den Scope festzurren, kannst eine Admission-Architektur mit Kyverno oder Gatekeeper begründen, hast einen Audit-zuerst-Rollout-Plan parat und kennst Antworten auf die Einwände, die bei diesem Thema fast immer kommen — Exceptions, Latenz im Admission-Pfad und „warum nicht einfach Code-Review?”.

Das Szenario: 80 Teams, null Tickets

Die Aufgabe, wie sie ein Interviewer stellen könnte: „Wir haben 80 Entwicklungsteams auf gemeinsamen Kubernetes-Clustern. Security verlangt verbindliche Guardrails — keine privilegierten Container, keine latest-Tags, Ressourcen-Limits überall. Heute prüft das ein Security-Team manuell per Ticket, und das skaliert nicht. Designe eine Policy-as-Code-Plattform.”

Der Kern des Cases ist ein Zielkonflikt: Teams sollen ohne Freigabeschleifen deployen, aber Compliance (hier: SOC2, also lückenlose Auditierbarkeit aller Änderungen) muss trotzdem garantiert sein. Wer im Interview sofort „Kyverno installieren” sagt, hat den Case verfehlt — die eigentliche Designleistung liegt im Rollout und in der Feedback-Schleife zu den Teams.

Anforderungen klären: Welche Fragen stellst du zuerst?

Fünf Rückfragen, die den Case strukturieren:

1. Welche Policies konkret, und wie kritisch sind sie? Im Szenario: kein latest-Tag, Readiness/Liveness-Probes verpflichtend, Resource-Limits verpflichtend, kein privileged: true. Das ist wichtig, weil daraus die Eskalationsstufe folgt: Ein fehlendes Limit kann warnen, ein privilegierter Container muss blocken.
2. Blocken oder erst nur melden? Die Antwort „Audit-Modus zuerst, dann Enforce” ist hier vorgegeben — wenn nicht, schlage sie selbst vor. Sofortiges Enforcement gegen 80 Teams mit Bestandsworkloads erzeugt einen Aufstand.
3. Wie erfahren Teams von Violations? Vorgabe: im Entwicklerportal sichtbar. Das heißt, du brauchst einen Weg von Policy-Reports zu einer Team-Ansicht — nicht nur Cluster-Events, die niemand liest.
4. Gibt es legitime Ausnahmen? Immer. Ein Monitoring-Agent braucht vielleicht Host-Zugriff. Ohne Exception-Prozess landet jede Ausnahme als Ticket beim Plattform-Team — genau das, was abgeschafft werden soll.
5. Was muss fürs Audit nachweisbar sein? SOC2 heißt: Wer hat wann welche Policy geändert, und welche Workloads haben wann verstoßen? Das spricht für Policies in Git mit Review-Pflicht.

Grobe Mengenabschätzung für das Gespräch: 80 Teams × grob 10 Services × 2–3 Umgebungen ≈ 2.000 Workloads. Bei jedem Deployment laufen Admission-Checks — der Webhook liegt also im kritischen Pfad jedes kubectl apply und jedes GitOps-Syncs. Latenz und Ausfallverhalten des Webhooks sind damit Designthemen, keine Fußnoten.

Architektur: Admission Controller plus Feedback-Schleife

Engine-Wahl. Kyverno und OPA Gatekeeper sind die beiden etablierten Optionen. Kyverno definiert Policies als Kubernetes-Ressourcen in YAML und kann neben Validieren auch Mutieren (z. B. fehlende Labels ergänzen) und Generieren (z. B. bei jedem neuen Namespace automatisch NetworkPolicy und ResourceQuota anlegen). Gatekeeper nutzt die Policy-Sprache Rego — mächtiger für komplexe Logik, aber eine eigene Sprache, die 80 Teams lesen können müssten. Begründete Wahl für diesen Case: Kyverno, weil die geforderten Policies Standardfälle sind und YAML die Hürde für Teams senkt. Sage im Interview dazu: „Bei komplexen organisationsweiten Regeln mit viel Logik würde ich Gatekeeper neu bewerten.”

Rollout in drei Phasen. Phase 1: alle Policies im Audit-Modus (validationFailureAction: Audit), 30 Tage Daten sammeln. Phase 2: Violations pro Team sichtbar machen — Kyverno schreibt PolicyReports als Kubernetes-Ressourcen, die du in ein Backstage-Plugin oder Dashboard ziehst, gefiltert nach Namespace-Ownership. Teams bekommen eine Frist. Phase 3: Umstellung auf Enforce, Policy für Policy, beginnend mit der unstrittigsten (kein privileged).

Exceptions als Produkt-Feature. Ausnahmen werden als deklarative Exception-Ressource im Git-Repo beantragt — mit Pflichtfeldern für Begründung und Ablaufdatum. Der Merge-Request ersetzt das Ticket: Review durch das Plattform- oder Security-Team, danach gilt die Ausnahme automatisch und läuft automatisch ab. Ohne Expiry sammelst du in zwei Jahren hunderte vergessene Löcher an.

Auditierbarkeit. Policies und Exceptions liegen in einem platform-policies-Repository und werden per GitOps ausgerollt. Git-Historie plus geschützte Branches liefern den SOC2-Nachweis fast nebenbei.

Failure-Mode des Webhooks. Admission-Webhooks haben eine failurePolicy: Fail blockt bei Webhook-Ausfall alle Deployments (sicher, aber die Plattform wird zum Single Point of Failure), Ignore lässt bei Ausfall alles durch (verfügbar, aber die Guardrails sind weg). Vertretbare Antwort: Fail für die sicherheitskritischen Policies, Engine hochverfügbar mit mehreren Replicas betreiben, und Monitoring auf Webhook-Latenz.

Einwände des Interviewers

„Warum reicht Code-Review nicht?” — Review skaliert nicht auf 80 Teams und prüft nicht, was zur Laufzeit wirklich im Cluster landet (Helm-Rendering, Operatoren, manuelle Änderungen). Admission Control prüft am einzigen Punkt, den nichts umgehen kann: der API.

„Was, wenn der Webhook down ist?” — failurePolicy erklären, differenziert nach Policy-Kritikalität, plus HA-Betrieb der Engine. Wer hier nur „dann geht nichts mehr” sagt, hat das Betriebsrisiko nicht durchdacht.

„Wie verhinderst du, dass Teams die Plattform hassen?” — Audit-first, Violations mit Erklärung und Fix-Hinweis im Portal, Exceptions in Minuten statt Tagen, und Vorlaufzeit vor jedem Enforce-Schalter. Policy-Plattformen scheitern an Adoption, nicht an Technik.

„Validierung reicht — warum Mutation und Generation?” — Weil Verhindern allein Arbeit auf Teams abwälzt. Automatisch generierte NetworkPolicies und Quotas bei Namespace-Erstellung machen den sicheren Weg zum Default-Weg.

Praxis

Spiele den Case unter Interviewbedingungen durch: 40 Minuten, Whiteboard oder Blatt Papier, laut sprechend. Diese fünf Punkte müssen vorkommen:

1. Mindestens vier Klärungsfragen, bevor du irgendein Tool nennst
2. Engine-Entscheidung mit Begründung und benannter Alternative
3. Der dreiphasige Rollout Audit → Sichtbarkeit → Enforce mit Zeitangaben
4. Exception-Prozess mit Expiry und Git-Review
5. Failure-Verhalten des Admission-Webhooks

Wiederhole die Übung nach drei Tagen und variiere die Vorgabe: Diesmal verlangt der Interviewer Enforce ab Tag 1 für eine einzige kritische Policy. Was änderst du?

Typische Stolperfallen

Enforce ab Tag 1 vorschlagen. Gegen Bestandsworkloads blockt das sofort laufende Deployments. Der Audit-Zeitraum ist keine Vorsicht, sondern Datengrundlage: Er zeigt dir, wie viele Violations real existieren, bevor du sie zu Fehlern machst.

Exceptions vergessen. Der Interviewer wartet oft nur darauf. Eine Policy-Plattform ohne Ausnahmeprozess produziert exakt die Ticket-Fabrik, die sie abschaffen sollte.

Nur über Tools reden. Kyverno-Feature-Listen beeindrucken niemanden. Bewertet wird, ob du Rollout, Team-Kommunikation und Audit-Nachweis als Teil der Architektur begreifst.

Den Admission-Pfad als gratis annehmen. Jede Policy kostet Latenz bei jedem API-Request. Bei 2.000 Workloads und GitOps-Syncs im Minutentakt ist das messbar — erwähne Monitoring der Webhook-Latenz.

Interview-Vorbereitung

Kernbotschaft in einem Satz: „Policy-as-Code verlagert Guardrails von manuellen Reviews an die Kubernetes-API — als Code in Git, mit Audit-first-Rollout, Team-Sichtbarkeit und ablaufenden Exceptions.”

Rechne mit diesen Follow-ups:

• „Kyverno oder Gatekeeper — und warum?” — Kyverno: Kubernetes-native YAML-Policies plus Mutate/Generate, niedrige Einstiegshürde. Gatekeeper: Rego für komplexe Logik. Entscheide nach Policy-Komplexität und danach, wer die Policies lesen muss.
• „Wie misst du den Erfolg der Plattform?” — Violations pro Team über Zeit (sollte sinken), Zeit bis zur Exception-Genehmigung, Anteil der Deployments ohne manuelle Security-Beteiligung.
• „Was passiert mit Workloads, die schon laufen und verstoßen?” — Admission greift erst beim nächsten Update. Für den Bestand: Background-Scans (Kyverno erzeugt Reports auch für existierende Ressourcen) plus Fristen statt Zwangslöschung.
• „Wer darf Policies ändern?” — Security und Plattform-Team via Pull Request mit Review-Pflicht; die Git-Historie ist der Audit-Trail.

Zusammenfassung

Der Policy-Case wird über den Rollout gewonnen, nicht über die Engine: Audit-Modus mit 30 Tagen Datensammlung, Violations sichtbar im Portal, dann Policy für Policy auf Enforce — flankiert von Exceptions mit Ablaufdatum und Policies in Git als SOC2-Nachweis. Kyverno ist für Standard-Guardrails die begründbare Default-Wahl, Gatekeeper die Alternative für komplexe Logik, und das Failure-Verhalten des Webhooks gehört in jede vollständige Antwort. In der nächsten Lektion wechselt die Perspektive vom Schützen zum Umziehen: 200 VM-Anwendungen sollen in 18 Monaten auf Kubernetes — ein Case, bei dem Priorisierung wichtiger ist als Architektur.