CVE-2026-22039: Wie eine Schwachstelle im Admission Controller Kubernetes-Namespaces zu einer Sicherheitsillusion machte
Wie die Diskussion begann
Habe gerade diese fiese Kyverno-CVE gesehen – ein perfektes Beispiel dafür, warum ich bei Admission Controllern mit God-Mode-RBAC skeptisch bin.
CVE-2026-22039 erlaubt es jedem Nutzer mit namespaced Policy-Rechten, Daten aus JEDEM Namespace zu exfiltrieren, indem die Variablensubstitution bei API-Calls missbraucht wird. Der Angreifer erstellt eine Policy in seinem eingeschränkten Namespace, löst sie mit Annotations aus, die auf kube-system-Ressourcen zeigen, und schwupps – Kyvernos cluster-admin-SA erledigt die Drecksarbeit für ihn.
Behoben in 1.16.3/1.15.3, aber das zeigt, wie diese Sicherheitstools selbst zum größten Angriffsvektor werden können.
Was in den Kommentaren auffiel
Diskussionspunkt 1
Das scheint eigentlich weder besser noch schlechter zu sein als die Million Snippet-Annotation-CVEs, die ingress-nginx in den letzten Jahren getroffen haben.
Diskussionspunkt 2
Ich meine... ja? Man sollte sich immer bewusst sein, wie viel Macht eine Anwendung hat. Die Kyverno-Docs enthalten jede Menge Warnhinweise dazu, wie eine falsch verwaltete Installation den Cluster blockieren, wichtige Nutzerkomponenten sperren kann usw. Kyverno ist meiner Meinung nach ein fantastisches Tool
Diskussionspunkt 3
Fairerweise muss man sagen, dass diese Art von Problem schon immer bei jeder Technologie existiert hat, die High-Level-Rechte braucht. Am Ende des Tages überwiegt aber wahrscheinlich bei weitem der Müll und die Probleme, die Kyverno vermutlich abgefangen und verhindert hat, gegenüber dieser einen CVE, und obwohl ich die CVE nicht gelesen habe, scheint die von dir gegebene Beschreibung nahezulegen, dass ein Angreifer überhaupt erst Zugriff auf einen Namespace bräuchte. Das reduziert die Angriffsfläche und Wahrscheinlichkeit ENORM. Wie bei so vielen Dingen geht es um das Threat Model. Ich sage sicher nicht, dass God-Mode-SAs und Admission Controller einfach ohne Weiteres erlaubt sein sollten, und dass deren Entwickler wirklich daran arbeiten sollten, die benötigten Rechte zu begrenzen (genau wie jeder andere, der Least Privilege befolgt), aber zu verstehen, was das für den eigenen Cluster bedeutet, ist ein großer Teil davon.
Diskussionspunkt 4
Ich habe vor ein paar Jahren an Kyverno mitentwickelt, und der Quellcode war ein einziges Trümmerfeld.
Diskussionspunkt 5
Namespaces sind keine Sicherheitsgrenzen und waren es nie. Tools wie vCluster „isolieren" unabhängige virtuelle Cluster über Namespaces, aber man muss Network Policies explizit aktivieren, um echte Ost-West-Netzwerkisolation zu erreichen. Zudem hat man im Standard-Worker-Node-Modell (shared/host) weiterhin alle Bedenken zu Container-Escapes, Noisy Neighbors und Lateral Movement, die es schon immer gab – PSA wird dadurch noch kritischer. Mit Tools wie vCluster wird es einfacher/besser, aber trotzdem war Multi-Tenancy, ausschließlich über Kubernetes umgesetzt, für Plattform-Teams immer ein komplexes Problem und wird es vermutlich bleiben. Wie bei so vielen anderen Sicherheitsthemen verweisen die Leute immer wieder darauf, dass Kubernetes vieles davon beim Design nicht berücksichtigt hat, und es brauchte SIGs, OSS-Community-Beteiligung und engagierte Organisationen, um in diesem Bereich Innovation voranzutreiben.
Thread-Übersicht
- Ursprüngliches Subreddit: r/kubernetes
- Ursprünglicher Autor: u/RemmeM89
- Reddit-Score: 79
- Kommentaranzahl: 24
- Ursprünglicher Thread: https://www.reddit.com/r/kubernetes/comments/1r44yxo/cve202622039_how_an_admission_controller/