Kubernetes v1.33 aktiviert User-Namespace-Isolation standardmäßig

In einem Beitrag im Kubernetes-Blog vom April 2025 gaben die Maintainer bekannt, dass Kubernetes v1.33 die Unterstützung für Linux-User-Namespaces standardmäßig aktiviert. Diese Änderung ermöglicht es Pods, eine stärkere Isolation zu nutzen, ohne dass Feature-Flags erforderlich sind, sofern die zugrunde liegende Infrastruktur bestimmte Kernel- und Runtime-Anforderungen erfüllt.

Was ist passiert?

Vor dieser Version erforderte die Nutzung von User-Namespaces in Kubernetes das explizite Aktivieren von Feature-Gates sowie komplexe Konfigurationsschritte. Mit Version 1.33 ist diese Funktion stabil und standardmäßig aktiv. Wenn die Anforderungen an den Stack erfüllt sind, können Nutzer sie einfach über die Pod-Spezifikationen aktivieren. Dieser Schritt markiert einen bedeutenden Fortschritt hin zu einer sicherheitsorientierten Container-Orchestrierung (Secure-by-Default) und reduziert die Hürden bei der Implementierung von Least-Privilege-Sicherheitsmodellen.

Die Ankündigung stellt klar, dass es sich um ein rein Linux-spezifisches Feature handelt. Sie unterscheidet zwischen Linux-User-Namespaces, die Benutzerkennungen auf Kernel-Ebene isolieren, und Kubernetes-Namespaces, die logische Cluster für Ressourcen darstellen. Das Update zielt darauf ab, Risiken im Zusammenhang mit Container-Escapes zu mindern, indem sichergestellt wird, dass Prozesse, die innerhalb eines Containers als Root laufen, auf dem Host-Knoten keine Root-Rechte besitzen.

Wie funktioniert es?

Linux-User-Namespaces isolieren die User IDs (UIDs) und Group IDs (GIDs) von Prozessen innerhalb eines Containers von denen des Hostsystems. Wenn ein Pod einen User-Namespace nutzt, werden die UIDs und GIDs im Container auf andere, nicht privilegierte Kennungen auf dem Host gemappt. Beispielsweise könnte ein Prozess, der im Container als UID 0 (Root) läuft, auf dem Host als UID 100000 erscheinen. Dieses Mapping stellt sicher, dass selbst wenn ein Container-Prozess seine Grenzen überschreitet, ihm die Berechtigungen fehlen, um Host-Dateien zu ändern oder als privilegierter Nutzer mit anderen Host-Prozessen zu interagieren.

Dieser Mechanismus stützt sich stark auf „idmap mounts“, eine Funktion des Linux-Kernels, die UID/GID-Mappings beim Zugriff auf gemountete Dateisysteme anwendet. Idmap mounts ermöglichen es jedem Pod, unterschiedliche UIDs auf dem Host zu verwenden, ohne manuelle Änderungen an den Dateibesitzverhältnissen (chown) auf Volumes vornehmen zu müssen. Dies vereinfacht das Volume-Management und ermöglicht Funktionen wie das Teilen von Volumes zwischen Pods mit unterschiedlichen User-Mappings. Allerdings müssen die für Volumes verwendeten Dateisysteme idmap mounts unterstützen. Die meisten gängigen Dateisysteme werden unterstützt, NFS fehlt jedoch derzeit auf den Unterstützungslisten.

Wichtige Details

• Opt-in-Mechanismus: Nutzer aktivieren die Funktion, indem sie hostUsers: false in der Pod-Spezifikation setzen.
• Kernel-Anforderungen: Ein Linux-Kernel der Version 6.3 oder höher wird empfohlen, um tmpfs für Secrets und Config Maps zu unterstützen. Kernel 5.19 ist die Mindestanforderung für overlayfs-Unterstützung.
• Runtime-Kompatibilität: Containerd in Version 2.0 oder höher ist erforderlich. CRI-O funktioniert out-of-the-box. Andere Runtimes, einschließlich cri-dockerd, unterstützen dieses Feature derzeit nicht in Kombination mit Kubernetes.
• Sicherheitsvorteile: Verhindert laterale Bewegungen zwischen Containern und stellt sicher, dass innerhalb des Namespaces gewährte Capabilities auf dem Host ungültig sind.
• Einschränkungen: Anwendungen, die direkte Host-Privilegien benötigen, wie das Laden von Kernel-Modulen, können keine User-Namespaces nutzen. NFS-Volumes werden nicht mit idmap mounts unterstützt.

Warum ist das wichtig?

Für Software-Ingenieure und Plattform-Teams adressiert dieses Update ein langjähriges Sicherheitsdilemma: Anwendungen aus Kompatibilitätsgründen als Root innerhalb von Containern auszuführen, während gleichzeitig das Risiko für den Host minimiert werden soll. Traditionell erforderte die Ausführung als Nicht-Root erhebliche Refactorings der Anwendung oder komplexe eigene Lösungen zur Verwaltung von Dateiberechtigungen. User-Namespaces ermöglichen es Teams, Anwendungen intern als Root auszuführen, ohne Host-Level-Privilegien zu gewähren, und entkoppeln so die Anwendungslogik effektiv von den Sicherheitsrestriktionen der Infrastruktur.

Die standardmäßige Aktivierung stärkt zudem die Abwehr gegen Container-Escape-Schwachstellen. Häufige CVEs wie CVE-2024-21626 und CVE-2022-0492 werden dadurch entschärft, da entkommene Prozesse nur noch nicht privilegierte Host-Identitäten beibehalten. Dies reduziert die Angriffsfläche für laterale Bewegungen, bei denen ein kompromittierter Container sonst auf Dateien oder Prozesse anderer Container auf demselben Knoten zugreifen könnte. Durch die Garantie einzigartiger Host-UIDs für jeden Pod erzwingt der kubelet eine Isolation, die zuvor konsistent schwer zu erreichen war.

Was Sie tun können