Kubernetes Webhook: Dynamische Admission-Regeln – einfach erklärt

Kubernetes Webhooks erweitern die Admission Control des API-Servers um eigene Regeln, ohne den Kubernetes-Quellcode zu verändern. Ein Webhook ist ein HTTPS-Endpunkt, den der kube-apiserver bei jeder passenden API-Anfrage aufruft, bevor das Objekt dauerhaft gespeichert wird. Im Gegensatz zum allgemeinen Webhook (ein reiner HTTP-Callback) ist ein Kubernetes-Admission-Webhook ein fester Bestandteil des Admission-Prozesses.

Zwei Arten von Webhooks

Zwei Konfigurations-Ressourcen der API-Gruppe admissionregistration.k8s.io/v1 registrieren Webhooks: MutatingWebhookConfiguration für mutierende, ValidatingWebhookConfiguration für validierende Webhooks. Der API-Server schickt bei jedem passenden Request ein AdmissionReview-JSON an den Endpunkt. Mutierende Webhooks antworten mit allowed und einem JSON-Patch, der das Objekt vor dem Speichern verändert (zum Beispiel Labels, Limits oder Sidecar-Container ergänzt). Validierende Webhooks antworten nur mit allowed oder lehnen das Objekt ab.

Ablauf im API-Server

  • Authentifizierung und Autorisierung laufen zuerst.
  • Danach folgt die Admission-Phase: mutierende Webhooks laufen VOR den validierenden.
  • Die Reihenfolge mehrerer mutierender Webhooks ist nicht garantiert; mit reinvocationPolicy: IfNeeded ruft der API-Server sie nach Mutationen erneut auf.
  • Erst nach bestandener Admission wird das Objekt dauerhaft gespeichert.

Wichtige Einstellungen

  • failurePolicy: Ignore lässt Anfragen bei Webhook-Ausfall durch, Fail blockiert sie – ein nicht erreichbarer Webhook mit Fail kann die Admission für eine Ressourcenart lahmlegen.
  • timeoutSeconds: Standard sind 10 Sekunden, kurze Timeouts sind empfohlen.
  • namespaceSelector und objectSelector begrenzen, welche Objekte den Webhook auslösen.
  • sideEffects muss None oder NoneOnDryRun sein.
  • clientConfig definiert den Endpunkt als url oder service samt caBundle für TLS.

Typische Einsätze

  • Defaulting: fehlende Felder ergänzen, etwa Ressourcen-Limits, Labels oder injizierte Sidecar-Container.
  • Policy-Enforcement: unerlaubte Konfigurationen ablehnen, zum Beispiel übermäßige Privilegien (siehe Pod Security).
  • Validierung eigener Ressourcen, die per CustomResourceDefinition entstehen.

Webhooks lassen sich auf beliebige Ressourcen anwenden: Sie prüfen zum Beispiel auch Headless Services, bevor diese persistiert werden. Häufig injizieren mutierende Webhooks Downward-API-Referenzen wie fieldRef auf den Pod-Namen in die Umgebungsvariablen von Containern.