In Lambda-Ausdrücken kann man in C# 14.0 jetzt Parameter-Modifizierer wie scoped, ref, in, out und ref readonly verwenden, ohne dabei den Datentyp benennen zu müssen.

Ein Beispiel: Für den Delegate

delegate bool Extract(string text, out T result);

musste man vor C# 14.0 Folgendes schreiben:

Extract ExtractOld = (string text, out int result) 
  => Int32.TryParse(text, out result);

Ab C# 14.0 können Entwicklerinnen und Entwickler im Lambda-Ausdruck die Nennung der Datentypen string und int weglassen, weil diese Datentypen aus dem Kontext bereits klar sind:

Extract ExtractNew = (text, out result) 
  => Int32.TryParse(text, out result);

Das geht allerdings nicht, wenn ein variadischer Parameter mit params zum Einsatz kommt:

Add AddOld = (out int result, params List data) 
  => { result = data.Sum(); return true; };

Nicht möglich ist also folgende Verkürzung:

Add AddNew = (out result, params data) 
  => { result = data.Sum(); return true; };

(rme)

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)