Einführung in Kyverno

Die Kubernetes-API kann bestimmte API-Anfragen selbst mit der Ausdruckssprache CEL prüfen, während Kyverno zusätzliche Policy-Abläufe bereitstellt. An einer gemeinsamen Kubernetes-Validierungsanforderung vergleichen Sie native ValidatingAdmissionPolicy und Kyverno im Betrieb und ordnen ein, wann die native Lösung genügt. Beispiel-Workloads veranschaulichen Auswertungsort und Rückmeldung.

CEL beschreibt Bedingungen, die Kubernetes und Kyverno ohne imperativen Kontrollfluss auswerten. Sie erweitern eine einfache Regel um sichere Feldzugriffe, Variablen sowie all und exists und betrachten CREATE sowie UPDATE. In der Lernumgebung variieren Sie fehlende und abweichende Felder und untersuchen, wie der Ausdruck darauf reagiert.

Eine Policy ist erst brauchbar, wenn sie nur die beabsichtigten Ressourcen erfasst. Sie vervollständigen eine ValidatingPolicy mit Geltungsbereich, CEL-Ausdruck und verständlicher Rückmeldung. Das DevNinjas Dojo, unsere Cloud-Lernumgebung, ermöglicht den Vergleich von Offline-Auswertung und Admission-Verhalten im Cluster für dieselben Policy-Fälle; dabei ordnen Sie Unterschiede zwischen beiden Ausführungspfaden ein.

Vor einer blockierenden Einführung muss der betroffene Ressourcenbestand nachvollziehbar sein. Sie vergleichen neue API-Anfragen mit Hintergrundprüfungen gespeicherter Ressourcen und ordnen die unterschiedlichen Ergebnisarten ein. In der Lernumgebung untersuchen Sie, welche Befunde vor dem Rollout noch geklärt werden sollten, bevor Sie eine blockierende Regel erwägen.

Eine Ausnahme benötigt Begründung, Verantwortung und einen eng begrenzten Geltungsbereich. Sie definieren in der Schulungsumgebung eine PolicyException über Policy-Referenz und Match-Bedingungen und untersuchen passende sowie unpassende Requests. In der Lernumgebung vergleichen Sie Audit und Deny; Sie diskutieren einen Rückweg für eine kontrollierte Einführung.

Mutationen können definierte Plattformstandards ergänzen, müssen aber vorhandene Konfiguration respektieren. In einer MutatingPolicy vergleichen Sie deklarative und gezielte Änderungen für einen Workload-Default. In der Lernumgebung untersuchen Sie Wiederholbarkeit, bestehende Werte und Konflikte und bewerten Idempotenz; anschließend diskutieren Sie, wie derselbe Prüfgedanke bei späteren Änderungen wiederverwendet werden kann.

Wenn Kyverno, ein GitOps-Controller und ein Benutzer dasselbe Feld ändern, kann ein dauernder Konflikt entstehen. Sie wenden mutateExisting auf ausgewählte Ressourcen an und beobachten über GitOps-Diff, Events und managedFields, wie konkurrierende Änderungen sichtbar werden. In der Lernumgebung diskutieren Sie Feldverantwortung, RBAC-Rechte und die Grenze zwischen diagnostischen Informationen und technischem Überschreibschutz.

Neue Namespaces benötigen je nach Plattform einheitliche Basisressourcen. Für passende Namespaces erzeugen Sie mit einer GeneratingPolicy Ressourcen aus Datendefinitionen und halten sie synchron. Im Lab vergleichen Sie dabei sichtbare Aktualisierungen, Konflikte und zurückgelassene Ressourcen und diskutieren sinnvolle Verantwortung sowie gemeinsame Grenzen zwischen Policy und Plattformteam.

Automatisches Löschen benötigt eine eindeutig festgelegte Zielmenge und passende Berechtigungen. Sie begrenzen eine DeletingPolicy mit Labels und CEL-Bedingungen und untersuchen Auswahl sowie Zugriffsgrenzen. Geeignete Beobachtungen unterstützen die Bewertung des beabsichtigten Geltungsbereichs, einschließlich der Ressourcen, die unangetastet bleiben sollen, vor einer möglichen Anwendung im Cluster.

Manche Regeln benötigen Daten außerhalb des aktuellen API-Requests. Anhand von Berechtigungen, Zieladressen, Authentifizierung, Timeout und Datenfrische vergleichen Sie Laufzeitzugriffe mit resource.Get und http.Get sowie den Cache von globalContext.Get, einschließlich Risiken durch Latenz, Ausfälle und Veraltung. GlobalContextEntry unter kyverno.io/v2 ist eine stabile unterstützende Ressource.

Ein Digest identifiziert Image-Inhalte über ihren Hash; 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 Identitäten, Issuer, Subjects und Registry-Grenzen ein. Im Mittelpunkt steht, welchen Beitrag Identitätsprüfung, Attestierungsinhalt und CEL-Entscheidung jeweils leisten.

Eine gültige Signatur allein reicht nicht aus; Image-Prüfung verbindet Vertrauensdaten mit ausgewählten Images. Sie vervollständigen eine ImageValidatingPolicy und variieren Signaturstatus, Identitätsbezug und Attestierungsinhalt, ohne den zulässigen Ausgang vorwegzunehmen. An den unterschiedlichen Rückmeldungen grenzen Sie fachliche Policy-Verletzungen von technischen Fehlern ab; validationActions behandelt Regelverletzungen, timeoutSeconds begrenzt die Wartezeit und failurePolicy steuert Fail-open oder Fail-closed.

Policy-Änderungen sollten vor dem Cluster-Rollout geprüft werden. Sie fixieren die Kyverno-CLI-Version und ergänzen Schema- sowie Verhaltenstests in einem CI-Job. In der Lernumgebung halten Sie im Vergleich beider Prüfwege fest, welche Prüfungen offline möglich sind und welche weiterhin einen Cluster benötigen.

Die Erreichbarkeit eines Admission Webhooks beeinflusst je nach Konfiguration Verfügbarkeit oder Durchsetzung. Sie untersuchen eine Störung anhand von ausgewählten Kubernetes-Metriken, Events und Kyverno-Logs im Cluster und beziehen failurePolicy sowie timeoutSeconds in die Hypothesenbildung ein. Nach einer Störung lässt sich die Funktionsfähigkeit mit geeigneten Prüfungen bewerten.

Ältere Policy- und ClusterPolicy-Bestände benötigen einen geplanten Übergang zu den CEL-basierten APIs. Sie ordnen eine Validierungsregel dem passenden Policy-Typ zu und führen dieselben Testfälle vor und nach der Migration aus. Im Peer-Review betrachten Sie Verantwortung, Beobachtungsphase, Freigabekriterien, Rückweg und die Grenzen der Übertragung auf eine Produktionsumgebung.