Neu in Kyverno

Die fünf Advisories vom 10.09.2026 sind nur in v1.19.1 behoben, nicht in 1.18. Critical ist GHSA-5qq8-67g6-4h2w (CVSS 9.9). Wer eine namespaced Policy (kyverno.io/v1) anlegen darf, umgeht mit percent-codiertem %2e%2e im urlPath eines apiCall die Namespace-Prüfung und kommt bis Cluster-Admin. Ein dokumentierter Workaround fehlt. Hinzu kommen vier High-Advisories. GHSA-c5qq-7g2q-cpqp (7.7) erlaubt auf demselben Weg Lesezugriff über Namespace-Grenzen. GHSA-q825-p383-r9v5 (7.6) betrifft SSRF und den Abfluss des ServiceAccount-Tokens über das Legacy-apiCall.service und GlobalContextEntry, denn Blocklist und Token-Regeln aus 1.18 deckten nur den CEL-HTTP-Pfad ab. GHSA-59v6-2x73-wfg4 (7.7, ab 1.16.0) betrifft globalContext aus NamespacedValidatingPolicy. Bei GHSA-5cjf-wwfg-pj4c (7.7, ab 1.14.0) überspringt ImageValidatingPolicy die Signaturprüfung für die ganze Ressource, sobald eine PolicyException passt, egal was in images und allowedValues steht. Die Fixes ändern Verhalten: Exceptions nehmen nur noch die gelisteten Images aus, und apiCall.service unterliegt jetzt der HTTP-Block- und Allowlist.

Seit 1.19.1 lehnt Kyverno globalContext in namespaced CEL-Policies ab, und zwar schon bei der Validierung der Policy und zusätzlich zur Laufzeit. Das gilt für die Validating-, Mutating-, Generating-, Deleting- und ImageValidating-Varianten. Das ist eine Verhaltensänderung in einem Patch-Release, Hintergrund ist GHSA-59v6-2x73-wfg4. Mandanten-Policies, die GlobalContextEntry-Daten lesen, müssen in clusterweite Policies umziehen.

Die CEL-Typen haben Feature-Parität erreicht. Damit sind ClusterPolicy und Policy, CleanupPolicy und ClusterCleanupPolicy sowie die Legacy-PolicyException kyverno.io/v2 offiziell abgekündigt. Anlegen und Ändern liefert eine Admission-Warnung. 1.19 ist das letzte Release mit vollem Support, die Entfernung ist für 1.20 geplant (geschätzt November 2026). Die Storage-Version der policies.kyverno.io-Typen bleibt in 1.19 v1beta1 und wechselt mit 1.20 auf v1, kyverno migrate schreibt gespeicherte Objekte um. Ab 1.19.1 zählt die Metrik kyverno_deprecated_api_requests_total die Legacy-Nutzung. kyverno apply und kyverno test machen Warnungen mit --warnings-as-errors zum CI-Fehler.

Im Chart kyverno-policies steht policyType per Default auf ValidatingPolicy statt ClusterPolicy. Ein Helm-Upgrade ohne gesetzten Wert tauscht die Pod-Security-Policies also gegen CEL-Policies aus. Ausnahmen aus policyExclude greifen danach nicht mehr, für ValidatingPolicy gelten vpolExclude und vpolExcludeByPolicy. Wer vorerst beim Legacy-Typ bleibt, setzt policyType: ClusterPolicy.

Der Helm-Chart 3.9 bezieht die CRDs über die neue Abhängigkeit kyverno-api, gesteuert über das bestehende crds.install. Wer CRDs getrennt ausrollt oder crds.install: false setzt, muss seinen CRD-Workflow vor dem Upgrade prüfen.

ImageValidatingPolicy wertet validationConfigurations.verifyDigest (Default true) jetzt tatsächlich aus und lehnt Images ohne Digest ab. Solange mutateDigest (ebenfalls Default true) bei Admission Tags in Digests umschreibt, fällt das kaum auf. Policies mit mutateDigest: false und Tag-Referenzen schlagen ab 1.19 fehl.

Das neue Flag --excludeBootstrapResources (Helm: features.excludeBootstrapResources.enabled, Default aus) nimmt Node und CertificateSigningRequest aus den Webhooks mit failurePolicy Fail. So entsteht kein Webhook-Deadlock, wenn der Cluster ohne laufende Kyverno-Pods neu startet. Der Preis: Policies auf diese Kinds werden nicht durchgesetzt. Node steht in den Chart-Defaults ohnehin in resourceFilters, praktisch betrifft das Flag also vor allem CSRs und angepasste Filter.

Loopback- und Metadata-Adressen sind per Default blockiert, Allow- und Blocklist sind konfigurierbar, und HTTP aus namespaced Policies ist ab Werk aus und muss per Flag freigeschaltet werden. Hintergrund ist SSRF-Missbrauch (CVE-2026-4789). Das gilt in 1.18 nur für den CEL-HTTP-Pfad (http.Get, http.Post); das Legacy-apiCall.service und GlobalContextEntry sind erst ab 1.19.1 abgedeckt.

HTTP-Aufrufe tragen ein eingeschränktes Token, mit dem der angerufene Server sich nicht mehr als Kyverno-Controller ausgeben kann (CVE-2026-41323). Auch das greift in 1.18 nur im CEL-HTTP-Pfad, über das Legacy-apiCall.service konnte das ServiceAccount-Token bis 1.19.1 weiter abfließen.

kyverno apply und kyverno test können jetzt Cleanup-Policies, HTTP- und Envoy-Authz-Policies sowie mutateExisting in MutatingPolicy, dazu kommt --exceptions-with-policies. Damit lässt sich die Migration weg von ClusterPolicy erstmals vollständig in der CI testen.

Ein neuer ConfigMap-Parameter steuert, welche Erfolgs-Events emittiert werden. In großen Clustern war das Event-Volumen bisher der Grund, Reporting ganz abzuschalten.

Ab 1.18 werden nur noch das aktuelle und das unmittelbar vorherige Release gepatcht, beschränkt auf kritische und hohe CVEs sowie schwere Fehler. Das sind rund drei Monate Community-Support je Linie. Wer längere Fristen braucht, muss den Upgrade-Takt anziehen.

Aus der Vorstufe v1beta1 werden stabile v1-APIs: ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy und DeletingPolicy, jeweils mit Namespaced-Variante, dazu PolicyException. v1alpha1 ist ab hier deprecated. Zu beachten: v1 wird ausgeliefert, die Storage-Version in etcd bleibt zunächst v1beta1.

Die JMESPath-Typen sind ab 1.17 abgekündigt. Der damalige Fahrplan sah für 1.18 und 1.19 nur noch kritische Fixes und die Entfernung mit 1.20 im Oktober 2026 vor. Neue Policies gehören ab sofort in die CEL-APIs. Mit 1.19 hat das Projekt den Plan angepasst: 1.19 ist das letzte Release mit vollem Support, die Entfernung ist für 1.20 im November 2026 (geschätzt) angesetzt.

Filtert, welche Ergebnisse überhaupt in Reports geschrieben werden, etwa nur Fail. In großen Clustern der wirksamste Hebel gegen aufgeblähte PolicyReports.

Hashes über md5, sha1 und sha256, x509.decode zum Prüfen von Zertifikatsinhalten, json.unmarshal und yaml.parse für eingebettete Dokumente, dazu time.now, time.truncate und time.toCron für Wartungsfenster-Logik.

ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy und ImageValidatingPolicy kommen als Beta unter policies.kyverno.io. Sie werten CEL aus statt JMESPath und liegen damit näher an den ValidatingAdmissionPolicies des API-Servers.

Namespace-Eigentümer können Regeln im eigenen Namespace durchsetzen, ohne clusterweite Rechte. Für Mandantentrennung der Hebel, um Policy-Autorschaft zu delegieren, ohne RBAC aufzuweiten.

Ausnahmen lassen sich per policyRefs, images-Mustern und matchConditions eng schneiden, statt eine Regel pauschal abzuschalten. Für Audits bleibt damit nachvollziehbar, wer wo genau ausgenommen ist.