Ein Kubernetes Admission Controller ist ein Prüf- und Änderungsschritt, den jede Anfrage an die Kubernetes-API durchläuft, bevor ein Objekt tatsächlich im Cluster gespeichert wird. Er kann ein Manifest ablehnen, wenn es gegen eine Regel verstößt, oder es vorher automatisch anpassen, zum Beispiel um ein fehlendes Label zu ergänzen. Ohne diesen Schritt würde jedes fehlerhafte oder unsichere Manifest ungeprüft in den Cluster gelangen.
Wer diesen Ablauf einmal verstanden hat, versteht auch, wie Werkzeuge wie Gatekeeper oder Kyverno eigene Policies durchsetzen, ohne den Kubernetes-Quellcode anzufassen.
Ich betreibe Kubernetes-Cluster in Produktion und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben (2024), mit einem eigenen Kapitel zu Governance und Security. Alle meine Beiträge zu Kubernetes findest du gesammelt auf der Seite Kubernetes.
Was ein Admission Controller in Kubernetes prüft
Jede Anfrage an den Kubernetes-API-Server durchläuft mehrere Stationen, bevor ein Objekt tatsächlich im Cluster ankommt. Zuerst stellt der API-Server fest, wer die Anfrage schickt, meist über das Zertifikat aus deiner Kubeconfig. Danach prüft er, ob dieser Nutzer die Aktion überhaupt darf, das übernimmt RBAC. Wie das Rechtemodell dahinter aufgebaut ist, steht in Kubernetes RBAC: Rollen und Rechte.
Erst danach kommen die Admission Controller ins Spiel, in zwei Durchgängen. Im ersten Durchgang dürfen Mutating Admission Controller das Manifest noch verändern, etwa ein Standard-Label ergänzen oder ein CPU-Limit setzen. Danach prüft Kubernetes, ob das veränderte Manifest formal gültig ist. Im zweiten Durchgang dürfen Validating Admission Controller das Ergebnis nur noch annehmen oder ablehnen, verändern dürfen sie nichts mehr. Erst wenn auch dieser Schritt durch ist, landet das Objekt im etcd und wird für den Cluster aktiv.
Kubernetes bringt schon eine Reihe fertiger Admission Controller mit, etwa für Standard-Storage-Klassen oder für Ressourcengrenzen je Namespace. Welche davon aktiv sind, entscheidet die Konfiguration des API-Servers, das ist Sache deiner Cluster-Admins. Eine vollständige Übersicht bietet die Kubernetes-Dokumentation zu Admission Controllern.
Kubernetes Admission Controller Webhook: eigene Regeln einhängen
Die eingebauten Admission Controller decken viele Standardfälle ab, aber eigene Regeln, etwa welche Image-Registries erlaubt sind, brauchen mehr Flexibilität. Dafür gibt es zwei besondere Admission Controller, die selbst keine Logik enthalten, sondern eine Anfrage an einen externen Dienst weiterreichen: den MutatingAdmissionWebhook und den ValidatingAdmissionWebhook.
Ein Kubernetes Admission Controller Webhook ist technisch nichts anderes als ein HTTPS-Endpunkt, den du selbst betreiben kannst oder der von einem fertigen Werkzeug mitgebracht wird. Kubernetes schickt bei jeder passenden Anfrage das Manifest an diesen Endpunkt und wartet auf eine Antwort: erlaubt, abgelehnt, oder im Fall des Mutating Webhooks ein verändertes Manifest. Genau diesen Mechanismus nutzen die beiden bekanntesten Policy-Werkzeuge im Kubernetes-Umfeld, Gatekeeper und Kyverno. Für einfache Prüfungen gibt es seit einigen Releases zusätzlich Validating Admission Policies: Regeln in der Common Expression Language, die der API-Server selbst auswertet, ganz ohne eigenen Webhook-Dienst.
Kubernetes Policies durchsetzen: Gatekeeper oder Kyverno
Beide Werkzeuge lösen dieselbe Aufgabe auf unterschiedliche Weise. Gatekeeper baut auf dem Open Policy Agent auf und beschreibt Regeln in der Sprache Rego, getrennt in eine wiederverwendbare ConstraintTemplate und eine konkrete Constraint, die diese Vorlage mit Werten befüllt. Kyverno verzichtet auf eine eigene Sprache und beschreibt Regeln als reines Kubernetes-YAML, das ein Muster im Manifest direkt vergleicht.
|
Gatekeeper |
Kyverno |
| Regelsprache |
Rego (Open Policy Agent) |
YAML-Muster |
| Objekte |
ConstraintTemplate, Constraint |
ClusterPolicy, Policy |
| Einstieg |
steilere Lernkurve, mächtig bei komplexer Logik |
schneller Einstieg für Kubernetes-Teams |
| Typischer Einsatz |
wiederverwendbare Regelwerke über mehrere Cluster |
Registry-, Label- und Ressourcenregeln |
Für den Einstieg würde ich zu Kyverno raten, wenn dein Team schon mit YAML arbeitet und keine neue Sprache lernen möchte. Für komplexere Regelwerke mit vielen Ausnahmen zahlt sich die Rego-Investition von Gatekeeper aus. In meinem eigenen Produktionscluster läuft Gatekeeper, weil ich Regeln über mehrere Cluster hinweg wiederverwenden wollte.
Ein Beispiel: nur Images aus einer vertrauenswürdigen Registry zulassen
Die folgende Kyverno-Policy schreibt vor, dass Container nur Images aus einer eigenen Registry ziehen dürfen. Sie läuft zunächst im Modus Audit, damit du erst siehst, welche Manifeste dagegen verstoßen würden, bevor du sie tatsächlich blockierst.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: nur-vertrauenswuerdige-registry
spec:
validationFailureAction: Audit
rules:
- name: registry-pruefen
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Nur Images aus registry.example.internal sind erlaubt."
pattern:
spec:
containers:
- image: "registry.example.internal/*"
match.any.resources.kinds legt fest, dass die Regel nur für Pods gilt. validate.pattern beschreibt das erwartete Muster für spec.containers[].image. Erst wenn validationFailureAction auf Enforce steht, lehnt Kubernetes ein passendes Manifest tatsächlich ab, im Audit-Modus landet der Verstoß nur im Policy-Report.
Resource Quotas und Limit Ranges: Policy ohne Webhook
Nicht jede Regel braucht einen Webhook. Zwei eingebaute Objekte lösen eine ähnliche Aufgabe, ohne dass du eine Policy-Engine installierst: ResourceQuota und LimitRange. Eine ResourceQuota begrenzt, wie viele Pods oder wie viel CPU und Speicher ein ganzer Namespace insgesamt anfordern darf, das schützt den Cluster davor, dass ein einzelnes Team alle Ressourcen belegt. Eine LimitRange setzt dagegen Minimum, Maximum und Standardwerte für einen einzelnen Pod oder Container, unabhängig von der Quota des Namespace.
Beide Objekte ergänzen Gatekeeper und Kyverno, sie ersetzen sie nicht. Eine ResourceQuota verhindert nicht, dass jemand ein Image aus einer falschen Registry zieht, und eine Policy-Engine setzt keine automatischen Standardwerte für Requests. In der Praxis kombiniere ich beides: LimitRange und ResourceQuota für die Ressourcengrenzen je Namespace, Gatekeeper für alles, was darüber hinausgeht.
Audit zuerst, Enforce später: Policies sicher einführen
Der größte Fehler beim Einstieg in Kubernetes Policies ist, eine neue Regel direkt im Enforce-Modus auf einen laufenden Cluster loszulassen. Ich habe das bei mir selbst einmal zu früh gemacht und damit ein Deployment blockiert, das seit Monaten unauffällig lief. Seitdem starte ich jede neue Regel im Audit-Modus oder im entsprechenden Reporting-Modus von Gatekeeper und beobachte eine Weile, welche vorhandenen Objekte dagegen verstoßen würden.
Erst wenn der Report keine unerwarteten Treffer mehr zeigt, schalte ich auf Enforce um, und auch dann zunächst nur für neue Objekte, nicht rückwirkend für bestehende. Diese Reihenfolge kostet ein paar Tage mehr, verhindert aber genau die Art von Ausfall, die eine gut gemeinte Regel sonst auslösen kann.
Häufige Fragen
Was ist der Unterschied zwischen Mutating und Validating Admission Webhook?
Ein Mutating Admission Webhook darf ein Manifest noch verändern, etwa ein Label ergänzen. Ein Validating Admission Webhook darf ein Manifest nur noch annehmen oder ablehnen. Kubernetes ruft immer zuerst alle Mutating Webhooks auf und erst danach die Validating Webhooks, damit die Validierung das endgültige, schon veränderte Manifest sieht.
Brauche ich Gatekeeper oder Kyverno, wenn ich schon RBAC nutze?
Ja, wenn du mehr als Zugriffsrechte steuern willst. RBAC entscheidet, wer eine Aktion ausführen darf, etwa einen Pod anlegen. Eine Policy-Engine wie Gatekeeper oder Kyverno entscheidet, wie dieser Pod aussehen darf, etwa welche Registry oder welcher Security Context erlaubt ist. Beide Ebenen ergänzen sich, keine ersetzt die andere.
Ersetzen Resource Quotas eine Policy Engine?
Nein. ResourceQuota und LimitRange setzen Grenzen für Ressourcen wie CPU und Speicher je Namespace oder Pod, mehr aber auch nicht. Für Regeln zu Images, Labels oder Security-Einstellungen brauchst du weiterhin Gatekeeper oder Kyverno.
Wie teste ich eine neue Kyverno Policy, ohne den Cluster zu blockieren?
Setze validationFailureAction zunächst auf Audit und sieh dir den Policy-Report an, bevor du auf Enforce umschaltest. So siehst du, welche vorhandenen Objekte gegen die neue Regel verstoßen würden, ohne dass ein einziges Deployment abgelehnt wird.
Wie du weitermachst
Admission Controller und Policies sind der dritte Baustein neben RBAC und Pod Security Standards, mit dem du einen Kubernetes-Cluster gegen unsichere Manifeste absicherst. Wie RBAC im Detail funktioniert, steht in Kubernetes RBAC: Rollen und Rechte, die Grundeinstellungen für Pods in Pod Security Standards in Kubernetes. Wer eigene Objekte statt fertiger Policy-Engines bauen möchte, findet den Einstieg in Kubernetes Operator und CRD erklärt.
Mein Vorschlag für den Einstieg: Installiere Kyverno oder Gatekeeper in einem Testcluster, schreibe eine einzige Regel im Audit-Modus und beobachte eine Woche lang den Report, bevor du überhaupt über Enforce nachdenkst.
Ausführlich mit allen Beispielen steht das in Kapitel 7 meines Kubernetes-Praxisbuchs bei Rheinwerk.
