Einführung in Kyverno

Kubernetes kann bestimmte API-Anfragen selbst mit der Ausdruckssprache CEL prüfen. An der Vorgabe "nur freigegebene Registries" vergleichen Sie eine native ValidatingAdmissionPolicy mit Kyverno. Zwei Beispiel-Workloads zeigen, wo die Regel ausgewertet wird und welche Rückmeldung Nutzer erhalten. Eine Entscheidungstabelle ordnet auch den Hybridweg ein, bei dem Kyverno eine native Policy erzeugt.

CEL ist die Ausdruckssprache, mit der Kubernetes und Kyverno Bedingungen prüfen. Sie erweitern eine einfache Regel um sichere Feldzugriffe, Variablen sowie all und exists. Testobjekte mit fehlenden und abweichenden Feldern zeigen sofort, wie der Ausdruck bei CREATE und UPDATE reagiert. Die Ergebnismatrix macht wahr, falsch und Fehler klar unterscheidbar.

Eine Policy ist erst brauchbar, wenn sie nur die beabsichtigten Ressourcen erfasst. Sie vervollständigen eine ValidatingPolicy mit Resource Matching, CEL-Regel und verständlicher Fehlermeldung. Danach führen Sie mit kyverno test erlaubte, abgelehnte, übersprungene und UPDATE-Testfälle aus. Für dieselben Testfälle vergleichen Sie das Offline-Ergebnis mit dem Admission-Verhalten im Cluster. Die Testübersicht bleibt als Nachweis im Repository.

Vor dem Blockieren müssen Sie wissen, wie viele und welche Ressourcen eine Policy treffen würde. Sie vergleichen Ergebnisse aus neuen API-Anfragen mit der Hintergrundprüfung bereits gespeicherter Ressourcen und ordnen pass, fail, skip, warn und error ein. Sie dokumentieren, welche Treffer erklärbar sind und welche vor dem Rollout korrigiert werden müssen. Policy Reports ersetzen keine vollständige Historie abgelehnter Requests.

Eine Ausnahme braucht einen Grund, einen Verantwortlichen und einen eng begrenzten Geltungsbereich. In der Schulungsumgebung ist PolicyException aktiviert und auf einen Verwaltungs-Namespace beschränkt. Mit Policy-Referenz und Match-Bedingungen legen Sie fest, welche Requests wirklich ausgenommen sind, und testen passende sowie unpassende Fälle. Erst danach wechseln Sie von Audit (beobachten) zu Deny (blockieren) und prüfen den dokumentierten Rückweg.

Plattformstandards lassen sich oft besser automatisch ergänzen als bei jedem Deployment manuell prüfen. In einer MutatingPolicy setzen Sie einen Workload-Default mit deklarativer ApplyConfiguration um und vergleichen ihn mit der gezielten Änderung per JSONPatch. Wiederholte Ausführung, bereits gesetzte Werte und widersprüchliche Eingaben zeigen, ob die Mutation idempotent bleibt und fremde Konfiguration respektiert. Der geprüfte Fall bleibt als Regressionstest im Repository.

Wenn Kyverno, ein GitOps-Controller und ein Benutzer dasselbe Feld ändern, kann ein dauernder Konflikt entstehen. Sie aktivieren die asynchrone Funktion mutateExisting für ausgewählte Ressourcen und beobachten, wie GitOps die Änderung im Übungsfall zurücksetzt. GitOps-Diff und Reconciliation-Events zeigen den Konflikt; managedFields hilft bei der Spurensuche, verhindert aber kein Überschreiben. Anschließend legen Sie Feldverantwortung und RBAC-Rechte fest.

Neue Namespaces benötigen häufig dieselben Basisressourcen. Mit einer GeneratingPolicy erzeugen Sie aus einer Datendefinition eine NetworkPolicy für klar markierte Namespaces und nehmen anschließend einen vorhandenen Namespace auf. Änderungen an Trigger und Synchronisierung zeigen, wann Kyverno aktualisiert, kollidiert oder Ressourcen zurücklässt. Sie dokumentieren, welches System die Ressource verwaltet und was bei entfernten Triggern geschieht; den Clone-Modus vergleichen Sie anhand eines vorbereiteten Traces.

Automatisches Löschen ist nur vertretbar, wenn die Zielmenge vorab eindeutig feststeht. In einem Wegwerf-Namespace begrenzen Sie eine DeletingPolicy mit Opt-in-Labels und CEL-Bedingungen. Eine separate Vorabfrage mit denselben Kriterien listet die Kandidaten; sie ist ein Sicherheitsschritt, keine Kyverno-Vorschaufunktion. Zusätzlich zu ihren Basisrechten braucht die Cleanup-Rolle für die Zielressourcen get, list, watch und delete. Events und eine abschließende Abfrage belegen Löschung und Erhalt.

Manche Regeln benötigen Informationen außerhalb des aktuellen API-Requests. resource.Get und http.Get lesen Daten zur Laufzeit und können die Prüfung durch Latenz oder Ausfälle belasten. globalContext.Get nutzt einen Cache, dessen Inhalt veralten kann. Eine Entscheidungsmatrix vergleicht Berechtigungen, erlaubte Zieladressen, Authentifizierung, Timeout und Datenfrische. Sie sehen auch, wann HTTP-Zugriffe für namespaced Policies freigeschaltet werden müssen. GlobalContextEntry bleibt experimentell und ohne Stabilitätszusage.

Ein Digest benennt ein unveränderliches Image. Eine erfolgreiche Signaturprüfung belegt die kryptografische Bindung an einen konfigurierten Schlüssel oder eine Identität; eine Attestierung liefert zusätzliche Aussagen zum Build. An einem Lieferkettenbeispiel ordnen Sie Schlüssel, OIDC-basierte keyless Identitäten, Issuer, Subjects und Registry-Grenzen ein. Eine Zuordnung von Risiko und Kontrolle hält fest, was Identitätsprüfung, Attestierungsinhalt und CEL-Entscheidung jeweils leisten.

Eine gültige Signatur allein reicht nicht aus. Mit vorbereiteten Images und Vertrauensdaten in einer lokalen Registry vervollständigen Sie angeleitet eine ImageValidatingPolicy. Eine Ergebnismatrix trennt vier Fälle: korrekt signiert, unsigniert, falsche Identität sowie gültig signierte Attestierung mit unzulässigem Inhalt. Dabei unterscheiden Sie Policy-Verletzungen von technischen Fehlern: validationActions behandelt verletzte Regeln, timeoutSeconds begrenzt die Wartezeit und failurePolicy entscheidet danach über Fail-open oder Fail-closed.

Policy-Änderungen sollten nicht erst im Cluster auffallen. Sie fixieren die Kyverno-CLI-Version im gemeinsamen Repository und ergänzen Schema- und Verhaltenstests in einem CI-Job. Ein fehlerhafter Policy-Commit stoppt zunächst die Pipeline; nach der Korrektur wird sie grün. Dabei halten Sie fest, welche Prüfungen offline möglich sind und welche weiterhin einen Cluster benötigen.

Fällt der Admission Webhook vollständig aus, kann Kubernetes legitime Deployments blockieren oder Kontrollen überspringen. Sie legen zunächst failurePolicy und timeoutSeconds fest. Danach macht ein vorbereiteter Fehler alle Webhook-Endpunkte unerreichbar. Über Metriken, Events und Logs verfolgen Sie die Ursache. Der Wiederanlauf über einen unabhängigen Admin-Zugang endet mit Funktionstests für einen erlaubten und einen regelverletzenden Request.

Ältere Policy- und ClusterPolicy-Bestände verschwinden nicht durch einen API-Wechsel. Sie übertragen eine Validierungsregel in den passenden CEL-basierten Policy-Typ und führen dieselben Testfälle vor und nach der Migration aus. Stimmen erlaubte, abgelehnte, übersprungene und ausgenommene Fälle überein, dokumentiert das Peer-Review Verantwortliche, Beobachtungsphase, Freigabekriterien und den Rückweg.