Kubernetes 1.37 hebt den Rootless-Modus auf Beta

Kubernetes v1.37 hebt das Feature Gate KubeletInUserNamespace auf Beta. Ist es aktiv, kann jede Node-Komponente als gewöhnlicher Benutzer statt als root laufen. Akihiro Suda von NTT kündigte die Änderung am 4. September 2026 im Kubernetes-Blog an. Das Release v1.37.0 selbst erschien am 26. August 2026.

Es geht um Schadensbegrenzung. Wer aus einem Container ausbricht, landet in einem unprivilegierten Konto statt als root auf der Maschine.

Was tatsächlich ohne root läuft

Suda nennt vier Arten von Node-Komponenten, die das Feature abdeckt:

• das Kubelet
• CRI- und OCI-Container-Runtimes
• CNI-Netzwerk-Plugins
• kube-proxy

Sie alle "can run as a non-root user on the host, using a Linux user namespace", schreibt er. "This technique is also known as rootless mode."

Ein User Namespace ist eine Funktion des Linux-Kernels. Ein Prozess hält sich darin für root, während der Host ihn weiterhin als normalen Benutzer behandelt. Die Rechte sind innerhalb des Namespace echt und außerhalb nicht vorhanden.

Das ist das ganze Sicherheitsargument. Suda benennt den Anlass deutlich: Die Node-Komponenten hatten "historically had container-breakout vulnerabilities that could compromise full root privileges on the host." Sein Beitrag nennt fünf davon.

• CVE-2022-0811
• CVE-2023-27561
• CVE-2024-10220
• CVE-2025-31133
• CVE-2026-53488

Im Rootless-Modus erreicht ein Ausbruch über eine dieser Lücken ein normales Benutzerkonto. Er erreicht nicht root auf dem Host.

Die Unterscheidung, die viele verwechseln werden

Es gibt in Kubernetes zwei verschiedene Funktionen rund um User Namespaces, und sie sind leicht zu verwechseln.

Suda zieht die Grenze selbst. Der Rootless-Modus "should not be confused with user namespaces for pods", schreibt er. Diese andere Funktion schaltet man mit hostUsers: false und dem Feature Gate UserNamespacesSupport ein. Sie ist seit v1.36 allgemein verfügbar. Sie "puts pods in user namespaces but still runs the node components as root."

Die eine steckt also Ihre Workloads in einen Namespace. Die andere steckt die Maschinerie hinein. Sie lösen verschiedene Hälften desselben Problems, und laut Beitrag lassen sie sich kombinieren.

Sieben Jahre vom Experiment zur Beta

Diese Funktion hat sich langsam bewegt, und die Daten sagen etwas über ihre Schwierigkeit.

Stufe	Wann
Erstes Experiment	2018
Alpha, als KEP-2033	v1.22, im Jahr 2021
Beta	v1.37, im Jahr 2026

Zwischen Alpha und Beta lagen fünf Jahre. Das Kubelet ohne root zu betreiben berührt Container-Runtimes, Netzwerk-Plugins und cgroup-Verwaltung zugleich, und jedes davon musste eigene Unterstützung dafür entwickeln.

Ein KEP ist ein Kubernetes Enhancement Proposal, das schriftliche Entwurfsdokument, das eine solche Änderung durchlaufen muss. Es ist dieselbe Art von Verfahren, das GNOME gerade für sich entwirft.

Was das für Entwickler bedeutet

Prüfen Sie zuerst, wer Ihr Kubelet betreibt. Wer einen verwalteten Dienst wie EKS, GKE oder AKS nutzt, kontrolliert diesen Prozess nicht, und kann die Funktion nicht selbst einschalten. Sie zählt vor allem für Leute mit eigenen Nodes, für Testcluster und für Edge-Installationen.

Lesen Sie vor einem Versuch die Ankündigung mit den Voraussetzungen. Der Rootless-Modus stützt sich auf bestimmtes Kernel-Verhalten, bestimmte Runtime-Versionen und cgroup-Delegation, und Sudas Beitrag ist der Ort für diese Einzelheiten. Nehmen Sie nicht an, dass Ihr aktuelles Node-Image genügt.

Behandeln Sie Beta als Beta. In Kubernetes heißt das: Die Form der API ist einigermaßen gesetzt, die betrieblichen Kanten sind es nicht, und Feature Gates können zwischen Releases noch ihre Standardwerte ändern. Betreiben Sie das dort, wo ein Verlust verkraftbar ist.

Die nützliche Erkenntnis gilt auch, wenn Sie die Funktion nie einschalten. Fragen Sie, was ein Container-Ausbruch auf Ihren Nodes heute tatsächlich erreicht. Für die meisten Cluster lautet die ehrliche Antwort root auf dem Host, und diese Antwort ist jetzt eine Entscheidung statt einer Selbstverständlichkeit.