Kubernetes Admission Controllers & Policy Engines — Kyverno vs. OPA Gatekeeper

Dieses 120-Minuten-Modul löst eine Ankündigung ein, die im Modul “Kubernetes Security Vertiefung” bewusst offen blieb: Pod Security Admission, das ihr dort kennengelernt habt, kann nur die drei vordefinierten Profile privileged/baseline/ restricted durchsetzen – für eine eigene Regel wie “jeder Pod braucht ein Label team” reicht das nicht. Ihr startet deshalb mit dem gemeinsamen Unterbau: Sowohl Pod Security Admission als auch die beiden Policy-Engines dieses Moduls klinken sich in denselben Admission-Webhook-Prozess ein – ein Objekt wird geprüft, bevor es angelegt wird. Dieser Mechanismus wird hier als bekannt vorausgesetzt und nicht erneut erklärt. Danach stellt ihr Kyverno und OPA Gatekeeper einander konzeptionell gegenüber: Kyverno beschreibt eine Regel als reine ClusterPolicy in YAML mit Pattern-Matching gegen das Objekt – wer Kubernetes-Manifeste lesen kann, liest auch eine Kyverno-Policy. OPA Gatekeeper trennt die Regel in zwei Objekte: eine ConstraintTemplate mit der eigentlichen Logik in der Policy-Sprache Rego, und eine Constraint-Instanz, die diese Logik mit konkreten Parametern auf bestimmte Objekte anwendet – wiederverwendbare Logik, getrennt von ihrer Konfiguration. Im ersten Hands-on installiert ihr Kyverno und schreibt eine ClusterPolicy, die genau eine Regel durchsetzt: jeder Pod braucht das Label team, sonst wird er live abgewiesen. Im zweiten Hands-on löst ihr dieselbe Regel mit OPA Gatekeeper – derselbe Regelverstoß, live gesehen, aber über ConstraintTemplate und Rego statt über ein YAML-Pattern. Genau dieser direkte Vergleich an derselben Regel macht den Unterschied zwischen beiden Ansätzen greifbar, statt ihn nur zu behaupten. Zum Abschluss ein kurzer Ausblick ohne eigenes Hands-on auf CI/CD-Policy-Gates – dieselbe Regel bereits vor dem Deployment in der Pipeline prüfen, statt erst am Cluster – vertieft im eigenständigen Aufbaumodul CI/CD Policy Gates — Policy-as-Code vor dem Deployment mit Kyverno-CLI & conftest. Explizit ohne Tool-Empfehlung: Dieses Modul sagt nicht, welche der beiden Engines “Standard” ist oder einen größeren Marktanteil hat – das bleibt unbelegt und unbenannt, ihr lernt beide Ansätze gleichrangig kennen und entscheidet selbst. Voraussetzung ist das Modul “Kubernetes Security Vertiefung” – RBAC/ServiceAccounts aus “Kubernetes Administration” und der Admission-Mechanismus selbst gelten als bekannt und werden hier nicht wiederholt. Die Session läuft vollständig lokal über Minikube, ohne Cloud-Account und ohne Kostenwirkung.