Kubernetes 1.37 hebt KubeletInUserNamespace auf Beta. Damit können zentrale Node-Komponenten wie Kubelet, CRI-/OCI-Runtime, CNI-Komponenten und kube-proxy innerhalb eines Linux User Namespace laufen, während der zugehörige Prozess auf dem Host selbst kein echter Root-Benutzer ist. Das reduziert den möglichen Schaden, wenn eine dieser Komponenten kompromittiert wird.
Warum das mehr ist als 'Container laufen nicht als root'
Rootless Kubernetes auf Node-Ebene darf nicht mit einem gewöhnlichen securityContext für einzelne Pods verwechselt werden. Ebenso ist es nicht dasselbe wie die seit Kubernetes 1.36 allgemein verfügbare User-Namespace-Unterstützung für Pods. Bei KubeletInUserNamespace geht es um die privilegierte Infrastruktur des Nodes selbst.
Ein Linux User Namespace kann UID 0 innerhalb des Namespace auf einen normalen, unprivilegierten Benutzer des Hosts abbilden. Für Prozesse im Namespace sieht diese Identität wie Root aus und reicht für viele Aufgaben wie Mounts, Cgroups und Netzwerk-Namespaces. Außerhalb des Namespace besitzt sie aber nicht automatisch die Rechte von Host-Root.
Der Sicherheitsgewinn ist konkret
Das Kubernetes-Projekt begründet die Funktion ausdrücklich mit historischen Container- und Node-Breakouts. Genannt werden unter anderem Schwachstellen in CRI-O, runc, kubelet und containerd, bei denen ein erfolgreicher Angriff bis zu Root-Codeausführung oder kritischen Host-Zugriffen führen konnte. Wenn die kompromittierte Komponente auf dem Host nur als unprivilegierter Benutzer läuft, wird dieser Blast Radius reduziert.
Das ist Defense in Depth, kein Allheilmittel. Kernel-Schwachstellen werden durch User Namespaces nicht automatisch unschädlich. Kubernetes empfiehlt deshalb weiterhin klassische Härtung wie seccomp und eine möglichst kleine Angriffsfläche.
Der Satz, den Admins nicht falsch lesen sollten
Mit 1.37 ist der Feature-Gate KubeletInUserNamespace standardmäßig aktiviert. Das klingt schnell so, als würden bestehende Cluster nach dem Upgrade automatisch rootless betrieben. Genau das passiert nicht.
Die Kubernetes-Ankündigung stellt ausdrücklich klar, dass das Aktivieren des Gates den Kubelet nicht automatisch in einen User Namespace verschiebt. Der Namespace muss außerhalb von Kubernetes vorbereitet werden. Bestehende klassische Cluster bleiben daher nach einem normalen Versionsupgrade weiterhin „rootful“.
Was für einen echten Rootless-Node zusätzlich nötig ist
Die Dokumentation nennt unter anderem Cgroup v2, eine systemd-User-Session sowie passende /etc/subuid- und /etc/subgid-Zuordnungen. Je nach Umgebung sind zusätzliche sysctl-, Kernel- und Runtime-Einstellungen nötig.
Auch die Kompatibilität ist nicht vollständig unsichtbar. Bestimmte CNI- und CSI-Treiber können Operationen benötigen, die innerhalb des User Namespace nicht wie in einer klassischen Root-Umgebung funktionieren. Kubernetes 1.37 meldet deshalb mit runningInUserNamespace nun auch, ob ein Node tatsächlich in einem User Namespace läuft. Betreiber können diese Information für Labels, Taints oder Scheduling-Regeln verwenden.
Interessant für AI-Sandboxes und verschachtelte Cluster
Das Kubernetes-Team nennt selbst AI-Sandboxes als Einsatzfall. Ein Entwickler kann einen unprivilegierten lokalen Benutzer für einen Coding-Agenten und dessen Testcluster verwenden. Selbst wenn der Agent innerhalb des Clusters weitreichende Rechte erhält, ist die Host-Grenze stärker als bei einem vollständig privilegierten Node-Prozess.
Zusammen mit User Namespaces für Pods entstehen außerdem sauberere Kubernetes-in-Kubernetes-Szenarien. Das ist für CI, kurzlebige Testumgebungen und isolierte Agenten-Workloads technisch interessanter als die oft simplere Frage, ob ein einzelner Container UID 0 sieht.
Pandorex View
Rootless Node-Komponenten sind keine spektakuläre Funktion für Produktdemos. Genau deshalb ist die Änderung relevant. Kubernetes entfernt hier an einer besonders sensiblen Stelle unnötige Host-Privilegien, ohne zu behaupten, damit jede Container-Escape-Klasse zu lösen.
Der größte Kommunikationsfehler wäre die Formulierung „Kubernetes 1.37 läuft jetzt standardmäßig rootless“. Richtig ist: Der notwendige Feature-Gate ist standardmäßig aktiv; die rootless Laufzeitumgebung bleibt eine bewusste Betriebsentscheidung.
Relevanz: 8/10 · Security-Nutzen: 9/10 · Admin-Relevanz: 9/10