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)

Die neue Episode von software-architektur.tv widmet sich einem zentralen Thema des Cloud-Computings: der Migration einer Anwendung von einem Hyperscaler zu einem anderen Cloud-Anbieter. Lucas Dohmen und Eberhard Wolff gehen in ihrem Gespräch der Frage nach, wie ein Hyperscaler-Exit gelingen kann.

Anhand eines konkreten Fallbeispiels aus der Praxis skizziert Lucas Dohmen die Vorgehensweise. Gemeinsam mit dem Team von fejo.dk, einem der meistgenutzten Portale für Ferienhäuser in Dänemark, hat er die Anwendung von Amazon Web Services (AWS) in die Hetzner Cloud umgezogen. Lucas Dohmen detailliert im Verlauf des Gesprächs im Detail, wie sie dabei vorgegangen sind. Er zeigt die Vorteile auf, benennt aber auch die Herausforderungen, die sie lösen mussten, und beschreibt, wie ein solcher Weg typischerweise aussieht.

Livestream am 20. Februar

Die Ausstrahlung findet am Freitag, 20. Februar 2026, live ab 13 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zu den Folgen finden sich auf der Videocast-Seite.

(map)

Wie Microsoft verkündet hat, ist die Python Environments Extension für Visual Studio Code nach einer einjährigen Preview-Phase allgemein verfügbar. Sie soll den Workflow im Umgang mit Python-Umgebungen konsistenter gestalten und der Fragmentierung über Tools wie venv, conda, poetry und pipenv hinweg entgegenwirken.

Innerhalb der nächsten Wochen sollen alle Python-Environment-Workflows automatisch zur neuen Extension wechseln. Wer sie bereits jetzt verwenden möchte, kann die Einstellung python.useEnvironmentsExtension setzen. Die Erweiterung funktioniert im Zusammenspiel mit der Python-Extension und soll kein weiteres Setup benötigen.

Das bewirkt die Extension

Die Python Environments Extension erkennt beim Öffnen einer Python-Datei automatisch Umgebungen aller gängigen Technologien im Ökosystem: venv, conda, pyenv, poetry, pipenv und System-Python-Installationen. Dahinter steht das Python Environment Tool (PET), ein Rust-basierter Scanner zum Auffinden von Umgebungen. Dieses überprüft den PATH, bekannte Installationsorte und konfigurierbare Suchpfade.

In der Python-Extension kam PET bisher schon zum Einsatz, bietet nun jedoch zusätzlich ein dediziertes User-Interface zum Erstellen, Löschen, Wechseln und Verwalten von Umgebungen.

Sofern der Paketmanager uv installiert ist, nutzt die Python Environments Extension ihn automatisch, um venv-Umgebungen zu erstellen und Pakete zu installieren. Das soll insbesondere in großen Projekten deutlich schneller gelingen als mit Standard-Tools und ist per Default-Einstellung (python-envs.alwaysUseUv) aktiviert.

Umgebungen erstellen oder vorhandenen Projekten zuweisen

Um eine neue Umgebung zu erstellen, klicken Entwickler auf Quick Create (den +-Button in der Environment-Manager-Ansicht). Daraufhin erstellt die Extension eine neue Umgebung mit dem Standard-Manager, der neuesten Python-Version sowie Workspace Dependencies, die sie in den Dateien requirements.txt oder pyproject.toml auffindet. Eine benutzerdefinierte Erstellung ist mit Custom Create möglich, zugänglich via „Python: Create Environment“ in der Befehlspalette. Dann lassen sich die genannten Punkte manuell auswählen.

Zu den weiteren Features zählt, dass sich Umgebungen auf spezifische Ordner oder Dateien zuordnen lassen. Das soll gängige Probleme, unter anderem in Monorepos und im Umgang mit Multi-Version-Testing beheben. Wenn ein Projekt einer Umgebung zugewiesen ist, speichert die Extension den Environment-Manager-Typ, nicht aber hartkodierte Interpreter-Pfade. Dadurch ist die .vscode/settings.json-Datei über Geräte, Betriebssysteme und Teammitglieder hinweg portabel.

Darüber hinaus verwendet die Python-Extension nun die Python Environments API, um Multi-Project-Testing zu ermöglichen. Hinweise hierzu bietet die Anleitung auf GitHub.

Weitere Details hält der Blogeintrag zum Release der Python Environments Extension bereit. Sie ist im Visual Studio Marketplace zu finden, dort allerdings noch als Preview gekennzeichnet.

(mai)