Rootless Kubernetes:
Was der Beta-Status für Nodes ändert

Rootless Kubernetes führt Kubelet, Container Runtime, CNI und weitere Node-Komponenten in einem Linux User Namespace aus. Innerhalb dieses Namespace wirken sie wie Root; auf dem Host sind ihre Rechte jedoch einem unprivilegierten Benutzer zugeordnet. Kubernetes 1.37 hebt den dafür vorgesehenen Feature-Gate KubeletInUserNamespace auf Beta.

Das reduziert den möglichen Schaden bestimmter Container-Breakouts, macht einen bestehenden Cluster aber nicht automatisch rootless. Für Plattformteams ist der neue Status deshalb kein Upgrade-Häkchen, sondern ein Anlass für einen getrennten Kompatibilitätspilot. Netzwerk, Storage, privilegierte DaemonSets und der Rückweg auf klassische Nodes entscheiden, ob der Sicherheitsgewinn im eigenen Betrieb tragfähig ist.

Was Kubernetes 1.37 bei Rootless Nodes tatsächlich ändert

Der Kubernetes-Blog vom 4. September 2026 nennt drei konkrete Schritte: Der Feature-Gate ist standardmäßig aktiviert, Nodes melden den Zustand über runningInUserNamespace, und die Kubernetes-CI führt Node-Conformance-Tests auf einem rootless Cluster aus. Das ist relevante Reife-Evidenz.

Der wichtigste Satz steht direkt daneben: Der aktivierte Feature-Gate erzeugt keinen User Namespace und verschiebt keine laufenden Nodes. Die Umgebung muss außerhalb von Kubernetes vorbereitet werden. Die offizielle Administrationsdokumentation fordert unter anderem cgroup v2, eine systemd-Benutzersitzung, passende /etc/subuid- und /etc/subgid-Bereiche sowie einen kompatiblen Container- und OCI-Runtime-Stack.

Die Kubernetes Enhancement Proposal KEP-2033 zieht eine wichtige Betriebsgrenze: Kubelet und weitere Node-Komponenten müssen denselben User Namespace nutzen. Rollout und Rollback bedeuten typischerweise, Nodes neu zu erstellen. Ein In-place-Schalter auf einem belegten Node ist daher kein belastbarer Migrationsplan.

Node-Rootless und Pod User Namespaces lösen verschiedene Probleme

Die Kubernetes-Dokumentation zu Pod User Namespaces beschreibt hostUsers: false als separaten, seit Version 1.36 stabilen Mechanismus. Er ordnet Root im Container einem unprivilegierten Host-Benutzer zu. Rootless Nodes setzen eine Ebene tiefer an: Sie begrenzen die Host-Rechte der Komponenten, die Pods starten, Volumes einhängen und Netzwerke konfigurieren.

Beide Ansätze ergänzen sich, ersetzen aber weder Workload-Härtung noch eine saubere Clustergrenze. Ein Prozess im User Namespace nutzt weiterhin denselben Kernel. Der Kubernetes-Beitrag sagt ausdrücklich, dass Kernel-Schwachstellen dadurch nicht grundsätzlich mitigiert werden. Seccomp, minimale Linux Capabilities, Netzwerkisolation sowie AppArmor oder SELinux bleiben relevante Schutzschichten, soweit sie im rootless Stack funktionieren.

Der Sicherheitsgewinn endet an Kernel und Host-Abhängigkeiten

Das Sicherheitsziel ist enger als „der Node ist sicher“. Wenn ein Angreifer über eine Schwachstelle in Kubelet, Runtime oder einem Container ausbricht, sollen seine Rechte auf das unprivilegierte Hostkonto begrenzt bleiben. Änderungen an Kernel, Bootloader oder Firmware werden damit deutlich schwerer. Das ist eine zusätzliche Schadensbegrenzung, kein Nachweis, dass der Einbruch verhindert wurde.

Gleichzeitig verschiebt sich Komplexität in die Integrationsschicht. Die offizielle Rootless-Administrationsseite, zuletzt geändert am 2. August 2026, nennt cgroup v2 als Pflicht, externe Portweiterleitung für NodePorts und den Kubelet-Port sowie konkrete Einschränkungen: Viele nicht lokale Volume-Treiber, darunter NFS und iSCSI, funktionieren nicht; bei CNI-Plugins ist Flannel mit VXLAN als bekannter funktionierender Pfad genannt. Diese Liste ist keine Garantie für jede Version oder Konfiguration.

Kompatibilität vor dem Pilot als Abhängigkeitsmatrix erfassen

Beginnen Sie nicht mit einem Demo-Pod, sondern mit allen Komponenten, die außerhalb normaler Containergrenzen arbeiten. Für jede Komponente braucht die Matrix Zweck, benötigte Host-Ressource, aktuell gewährte Privilegien, rootless Verhalten, Testfall und Rückfalloption.

1. Node-Basis erfassen. Prüfen Sie Linux-Kernel, cgroup v2, systemd-Delegation, Sub-UID/Sub-GID-Bereiche sowie CRI- und OCI-Versionen.
2. Netzwerkpfad zerlegen. Listen Sie CNI, kube-proxy-Modus, NodePorts, Load-Balancer-Integrationen, DNS und Network Policies samt notwendiger Hostoperationen auf.
3. Storage real testen. Prüfen Sie jeden CSI-Treiber und jede Volume-Klasse mit Provisionierung, Attach, Mount, Schreiblast, Snapshot, Restore und Nodewechsel.
4. DaemonSets klassifizieren. Markieren Sie Agents mit hostNetwork, hostPID, hostPath, Gerätedateien oder privileged: true und hinterfragen Sie jede Ausnahme.
5. Betriebssignale sichern. Validieren Sie Logs, Metriken, Traces, Node-Druck, Disk-Fehler und Alarmierung auch dann, wenn /dev/kmsg oder Hostpfade anders erreichbar sind.

Diese Matrix verbindet den Sicherheitsgewinn mit einer nachprüfbaren Betriebsentscheidung. Für die Architektur lohnt sich ein Cloud- und DevOps-Scope mit klaren Betriebsgrenzen; Host-, Runtime- und Workload-Bedrohungen gehören parallel in das Cybersicherheitsdesign. Das bestehende Multi-Cloud-Kontrollmodell zeigt ergänzend, wie dieselbe Wirkung über unterschiedliche Plattformen getestet werden kann.

Sieben Tests für einen belastbaren Rootless-Kubernetes-Pilot

1. Separaten Node-Pool erstellen. Starten Sie mit reproduzierbarer Infrastruktur und nicht produktiven, repräsentativen Workloads statt mit einer Umstellung vorhandener Nodes.
2. Zustand sichtbar machen. Erfassen Sie runningInUserNamespace, vergeben Sie daraus eine kontrollierte Node-Kennzeichnung und dokumentieren Sie deren Quelle.
3. Scheduling standardmäßig sperren. Nutzen Sie Taints und explizite Tolerations, damit inkompatible DaemonSets und Host-abhängige Workloads nicht zufällig landen.
4. Positive Pfade ausführen. Testen Sie Deploy, Skalierung, Restart, Netzwerkverkehr, Secrets, ConfigMaps, persistente Daten und Observability unter realistischer Last.
5. Fehler provozieren. Unterbrechen Sie Runtime, Portweiterleitung, Storage und Node-Netzwerk. Prüfen Sie, ob Alarme, Eviction, Rescheduling und Wiederherstellung wie geplant funktionieren.
6. Sicherheitsgrenze belegen. Verifizieren Sie Host-UIDs, effektive Capabilities und verbotene Hostaktionen; ein laufender Pod allein belegt keinen Privilegiengewinn.
7. Rollback üben. Entziehen Sie den Pool, verschieben Sie Workloads auf klassische Nodes und stellen Sie Daten sowie Netzpfade wieder her. Messen Sie Dauer und manuelle Schritte.

Ein Pilot ist erfolgreich, wenn sowohl erlaubte Workloads funktionieren als auch ungeeignete Workloads vorhersehbar abgewiesen werden. Der erste produktive Einsatz sollte klein, reversibel und beobachtbar bleiben. Managed Kubernetes kann zusätzliche Grenzen setzen; prüfen Sie deshalb Distribution, Node-Image und Supportaussage des tatsächlichen Anbieters separat.

Häufige Fragen zu Rootless Kubernetes

Laufen Kubernetes-Nodes ab Version 1.37 automatisch ohne Root?

Nein. Der Beta-Feature-Gate KubeletInUserNamespace ist zwar standardmäßig aktiviert, erstellt aber selbst keinen User Namespace. Die Node-Komponenten laufen erst dann rootless, wenn die Umgebung außerhalb von Kubernetes entsprechend eingerichtet und gestartet wird.

Ist ein rootless Node dasselbe wie ein Pod mit hostUsers: false?

Nein. Ein rootless Node verschiebt Kubelet, Container Runtime, CNI und weitere Node-Komponenten in einen User Namespace. hostUsers: false isoliert dagegen einen einzelnen Pod, während die Node-Komponenten weiterhin Host-Root haben können. Beide Mechanismen lassen sich kombinieren.

Ersetzt Rootless Kubernetes seccomp, AppArmor oder SELinux?

Nein. User Namespaces begrenzen viele Privilegien gegenüber dem Host, schützen aber nicht grundsätzlich vor Schwachstellen im gemeinsam genutzten Kernel. System- und Workload-Härtung, minimale Capabilities, seccomp und passende Mandatory-Access-Control-Regeln bleiben notwendig, soweit der gewählte Stack sie unterstützt.

Sind rootless Kubernetes-Nodes bereits für Produktion geeignet?

Der Kubernetes-Status ist Beta, nicht General Availability. Ein produktiver Einsatz kann für kompatible Workloads vertretbar sein, sollte aber über einen separaten Node-Pool mit getesteten Netzwerk-, Storage-, Observability- und Rollback-Pfaden beginnen. Die Unterstützung der eingesetzten Distribution und Plattform muss separat geprüft werden.