Kubernetes v1.33: User Namespaces – Mehr Sicherheit ohne Mehraufwand

Mit Version 1.33, veröffentlicht am 23. April 2025, bringt Kubernetes ein Sicherheitsfeature in den Standardbetrieb, das bisher oft übersehen wurde, aber enorme Wirkung entfaltet: User Namespaces sind jetzt standardmässig aktiviert, eine stille Revolution in Sachen Container-Isolation.

Was sind User Namespaces – und warum sind sie wichtig?

Container laufen häufig mit Root-Rechten, zumindest innerhalb des Containers. Bisher bedeutete das im Ernstfall: Wer aus dem Container ausbricht, hat Root-Zugriff auf dem Host, genau das verhindern User Namespaces.

User Namespaces in Kürze:

• Trennen der Benutzer- und Gruppen-IDs (UIDs/GIDs) von Container und Host
• Container laufen scheinbar als „Root“, haben aber keine Root-Rechte auf dem Host
• Selbst bei einem Ausbruch ("Breakout") bleibt der Schaden auf ein Minimum begrenzt

Im Gegensatz zu klassischen Kubernetes-Namespaces (für Objekte) ist ein User Namespace eine Funktion des Linux-Kernels, die Prozessrechte isoliert.

Neben der Unterscheidung zu Kubernetes-Namespaces lohnt sich auch ein Blick auf andere Sicherheitsmechanismen im Vergleich:

Im Unterschied zu anderen Sicherheitsfunktionen wie AppArmor oder Seccomp, die einzelne Systemaufrufe oder Rechte begrenzen, setzen User Namespaces auf eine systemweite Trennung der Identitäten. Dadurch entfällt die Notwendigkeit, Rechte in aufwendigen Policy-Dateien zu definieren, die Isolation geschieht direkt auf Kernel-Ebene und ist damit robuster und einfacher in der Umsetzung.

Vorteile im Überblick:

Mit aktivierten User Namespaces entstehen gleich mehrere Sicherheitsvorteile:

• Verhinderung lateraler Bewegungen: Container A kann Container B nicht angreifen, selbst bei Escape-Versuchen, da sie unterschiedliche UIDs/GIDs auf dem Host nutzen.
• Erhöhte Isolierung: Auch wenn ein Container als „Root“ läuft, besitzt er keinerlei Host-Privilegien. Zugriff auf Host-Dateien, Prozesse oder Kernel-Features bleibt ausgeschlossen.
• Neue Anwendungsfälle möglich: Manche Tools oder Build-Systeme brauchen Root-Rechte – innerhalb eines User Namespace geht das sicher, ohne dem Host zu schaden (z. B. Docker-in-Docker, Buildah, Kubernetes in Kubernetes).

Aktivierung: So einfach geht’s

Seit Kubernetes v1.33 braucht es keinen Feature-Flag mehr. Die Funktion ist standardmässig aktiv.

apiVersion: v1
kind: Pod
metadata:
  name: userns-example
spec:
  hostUsers: false
  containers:
    - name: demo
      image: debian
      command: ["sleep", "infinity"]

Optional kann man Webhooks oder einen MutatingAdmissionController nutzen, um dies clusterweit zu erzwingen.

Technische Voraussetzungen:

• Linux Kernel ≥ 6.3 für volle Unterstützung (inkl. tmpfs, projected volumes)
• Container Runtime mit User Namespace Support (z. B. containerd ≥ 2.0, CRI-O voll funktionsfähig)
• Dateisysteme mit idmap mounts-Support (z. B. ext4, XFS, overlayfs – NFS derzeit nicht unterstützt)
• Ältere Kernel wie 5.19 funktionieren mit Einschränkungen (kein tmpfs, kein Service Account Token Mount)

CVEs, die damit entschärft werden:

• CVE-2024-21626 – Container-Ausbruch über fehlende UID-Isolation
• CVE-2022-0492 – Rechteausweitung durch falsche Rechtevergabe

Eine umfangreichere Liste findet sich im offiziellen KEP 127 (GitHub).

Für Backup ONE-Kunden bedeuten standardmässig aktivierte User Namespaces ein deutlich höheres Sicherheitsniveau bei gleichzeitig reduzierter Komplexität. Besonders in Umgebungen mit gemischten Workloads oder mehreren Mandanten (Multi-Tenancy) bietet diese Isolationsebene einen echten Mehrwert. Durch den Wegfall aufwendiger Policy-Konfigurationen können Sicherheitsstandards einfacher und konsistenter umgesetzt werden. Dies passt nahtlos in unsere Philosophie: Sicherheit, die einfach funktioniert.

User Namespaces als Bestandteil moderner Cloud-native-Architekturen:

In modernen Cloud-native-Umgebungen reicht es nicht, Anwendungen nur in Containern zu betreiben, auch deren Sicherheit muss automatisiert mitgedacht werden.

User Namespaces bieten hier einen wirkungsvollen Baustein: Sie ermöglichen „Root im Container, aber nicht auf dem Host“ und das ohne Anpassung des Applikationscodes.

Gerade in dynamischen Kubernetes-Umgebungen mit vielen Microservices oder mehreren Teams ist diese Trennung entscheidend, um Angriffsflächen zu minimieren und Sicherheitsrichtlinien wie DevSecOps, Least Privilege oder Zero Trust effektiv umzusetzen.

Herausforderung für manche Unternehmen könnte die Heterogenität bestehender Cluster sein: Nicht alle Kernel oder Container Runtimes sind sofort kompatibel. Hier unterstützt Backup ONE bei der Planung und Implementierung sicherer Kubernetes-Umgebungen.

Fazit:

Mit Kubernetes v1.33 wird ein zentrales Sicherheitskonzept zum neuen Standard. User Namespaces sind der einfachste und sicherste Weg, Container zu isolieren ohne Entwicklungsaufwand.

Sie machen aus „Root“ im Container einen ungefährlichen Papiertiger und bieten gleichzeitig die Freiheit, komplexe Build oder Runtime-Szenarien sicher umzusetzen.

Wer Kubernetes mit Backup ONE produktiv nutzt, sollte keine Pods mehr ohne hostUsers: false starten. Unser Team unterstützt gerne bei der Umsetzung dieser Best Practices.

Es ist ein kleiner Konfigurationsschritt mit grosser Wirkung und ein deutliches Signal, dass Kubernetes-Sicherheit längst nicht mehr bei Netzwerkrichtlinien aufhört, sondern schon beim Container-User beginnt.