Kyverno hat sich als Policy-as-Code-Werkzeug für Kubernetes etabliert, mit dem sich Richtlinien direkt als Kubernetes-Ressourcen definieren und durchsetzen lassen – von Validierung über Mutation bis hin zur Image-Verifikation. Das Tool begegnet so der wachsenden Komplexität beim Betrieb von Kubernetes-Clustern, indem es Sicherheits- und Compliance-Regeln als Code abbildet. Mit Version 1.17 vollzieht das CNCF-Projekt laut eigener Ankündigung nun einen strategischen Schnitt: Die in Version 1.16 eingeführte CEL-first-Architektur (Common Expression Language) verlässt den Beta-Status und wird zur stabilen Grundlage.

CEL-Policy-Typen erreichen GA-Status

Die zentrale Neuerung in Kyverno 1.17 ist laut CNCF-Blog die Promotion sämtlicher CEL-basierter Policy-Typen auf die API-Version v1. Damit gelten sie als stabil und produktionsreif. Im Einzelnen betrifft das: ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy, DeletingPolicy sowie PolicyException – jeweils inklusive ihrer Namespaced-Varianten (etwa NamespacedValidatingPolicy).

Die Common Expression Language ist dieselbe Ausdruckssprache, die der Kubernetes-API-Server selbst für seine nativen ValidatingAdmissionPolicies und MutatingAdmissionPolicies verwendet. Dem Kyverno-Entwicklungsteam zufolge soll der Wechsel zur CEL die Evaluierungsleistung spürbar verbessern und die Einarbeitungszeit für Plattform-Teams senken, da sie sich nur noch mit einer Sprache auseinandersetzen müssen.

Parallel dazu hat das Projekt die verfügbaren CEL-Funktionen erheblich ausgebaut. Neu hinzugekommen sind unter anderem Hash-Funktionen (md5, sha1, sha256), mathematische Rundung (math.round(value, precision)), das Dekodieren von X.509-Zertifikaten (x509.decode(pem)), Zufallsstring-Generierung, JSON- und YAML-Parsing sowie zeitbasierte Funktionen wie time.now() und time.toCron(timestamp), die etwa auch Policies für Wartungsfenster ermöglichen sollen.

Legacy-APIs werden abgekündigt – Migration empfohlen

Mit dem GA-Status der CEL-Policies geht eine klare Ansage an Bestandsnutzer einher: Laut der Ankündigung markiert Kyverno 1.17 die bisherigen Typen ClusterPolicy und CleanupPolicy offiziell als veraltet (deprecated). Diese JMESPath-basierten APIs bleiben in der aktuellen Version zwar funktionsfähig, sollen aber in einer künftigen Version vollständig entfallen – voraussichtlich noch im laufenden Jahr. Die Entwickler empfehlen ausdrücklich, neue Policies ausschließlich mit den CEL-basierten APIs zu schreiben, um den späteren Migrationsaufwand nicht weiter zu vergrößern.

Für Teams mit umfangreichen bestehenden Policy-Beständen stellt das Projekt einen Migrationsleitfaden bereit, der eine Feld-für-Feld-Zuordnung von Legacy-Konfigurationen zu den neuen Äquivalenten bieten soll. Beispielsweise wird das bisherige validate.pattern auf CEL-Ausdrücke in ValidatingPolicy abgebildet. Wer bislang ClusterPolicy-Regeln für Mutation, Validierung und Generierung in einem einzigen Objekt gebündelt hat, muss diese künftig auf die spezialisierten Typen ValidatingPolicy, MutatingPolicy und GeneratingPolicy aufteilen.

Multi-Tenancy: Namespaced Mutation und Generation

Bereits in Version 1.16 hatte Kyverno Namespaced-Varianten für Validierung, Cleanup und Image-Verifikation eingeführt. Version 1.17 schließt laut Ankündigung diese Lücke mit NamespacedMutatingPolicy und NamespacedGeneratingPolicy. Namespace-Besitzer können damit eigene Mutations- und Generierungsregeln definieren – etwa um automatisch Sidecar-Container zu injizieren oder Standard-ConfigMaps zu erzeugen –, ohne clusterweite Berechtigungen zu benötigen oder andere Mandanten zu beeinflussen. Damit soll echte Multi-Tenancy auf Policy-Ebene möglich werden.

Supply Chain Security und Observability

Für mehr Sicherheit in der Supply Chain bringt Kyverno 1.17 laut der Ankündigung Unterstützung für Cosign v3, um die Image-Verifikation mit dem sich weiterentwickelnden Sigstore-Ökosystem kompatibel zu halten. Die neuen YAML- und JSON-Parsing-Funktionen in CEL sollen es zudem erleichtern, komplexe Metadaten und Software Bill of Materials (SBOMs) innerhalb von Attestierungen zu prüfen.

Bei der Observability haben die Entwickler an zwei Stellschrauben gedreht: Ein neues Flag --allowedResults ermöglicht es, gezielt nur bestimmte Ergebnisse (etwa ausschließlich fehlgeschlagene Prüfungen) in Reports zu speichern. Das soll den Druck auf etcd in großen Clustern deutlich reduzieren. Darüber hinaus liefert Kyverno 1.17 laut dem Blogbeitrag standardmäßig detailliertere Latenz- und Ausführungsmetriken für CEL-Policies.

Neue Website und entkoppelte Entwickler-Tools

Neben den technischen Neuerungen hat das Kyverno-Projekt seinen gesamten Webauftritt auf Basis des Starlight-Frameworks neu gestaltet. Die überarbeitete Dokumentation umfasst eine nach Nutzererfahrung gestaffelte Struktur – vom Schnelleinstieg bis zur Referenz für fortgeschrittene Policy-Autoren. Der Katalog mit über 300 Beispiel-Policies soll sich nun nach Kategorie und Typ (CEL vs. JMESPath) filtern lassen.

Für Entwickler und Integratoren hat das Projekt seine Kernkomponenten entkoppelt: Die CEL-basierten APIs sind in ein eigenes Repository (kyverno/api) ausgelagert worden, was den Import von Kyverno-Typen in eigene Go-Projekte erleichtern soll. Zusätzlich steht ein dediziertes SDK-Projekt (kyverno/sdk) für den Bau eigener Controller und Tools bereit.

Roadmap: Einheitliche Tooling-Plattform angestrebt

Für die weitere Entwicklung skizzieren die Kyverno-Maintainer mehrere Schwerpunkte: Die verschiedenen Unterprojekte – CLI, Policy Reporter und Kyverno-Authz – sollen zu einer einheitlichen Plattform zusammenwachsen. Zudem will das Team automatisierte Performancetests etablieren und granulare Durchsatz- sowie Latenz-Daten bereitstellen, damit Plattform-Teams das Verhalten von Kyverno in Hochlast-Szenarien besser einschätzen können. Ein Upgrade von Version 1.16 auf 1.17 soll laut den Entwicklern unkompliziert sein, allerdings empfehlen sie, Manifeste auf die neue API-Version v1 umzustellen. Die bisherige v1beta1 werde für eine Übergangszeit weiter unterstützt.

(map)