Kubernetes-Benutzernamensräume sind in GA und verändern das Sicherheitsmodell von Containern. Dies verringert das Risiko von Privilegieneskalationen, ohne die Konfiguration zu verkomplizieren.
Das Problem zeigt sich auf der Ebene der Prozessidentität. Ein Containerprozess mit UID 0 bleibt für den Hostkernel root. Bei einer Kernelanfälligkeit oder einem Fehler im Mount führt dies zu vollem Zugriff auf den Knoten. Die aktuellen Isolationsmechanismen verringern die Angriffsfläche, ändern jedoch nicht das Identitätsmodell selbst. Dies schränkt die sichere Nutzung von Privilegien innerhalb des Containers ein.
Die Lösung sind Kubernetes-Benutzernamensräume im GA-Status. Bei der Einstellung hostUsers: false wird in einem separaten Benutzernamensraum gestartet. Privilegien werden namespaced. Zum Beispiel gibt CAP_NET_ADMIN nur Kontrolle über die Ressourcen des Containers und nicht des Hosts. Dies ist ein Kompromiss: Es bleibt die Möglichkeit, Privilegien zu nutzen, aber die Grenzen ihres Geltungsbereichs werden lokal.
Die wesentliche ingenieurtechnische Herausforderung lag nicht im API, sondern im Dateisystem. Frühe Implementierungen erforderten ein rekursives chown von Volumes beim Mapping von UID. Für große Volumes zerstörte dies die Startzeit und erhöhte die IO-Last. Das Problem wird durch ID-mapped mounts aus Linux 5.12+ gelöst. Der Kernel führt die Übersetzung von UID/GID während des Mountvorgangs durch. Für den Container erscheinen Dateien als im Besitz von UID 0, aber auf der Festplatte ändert sich der Besitz nicht. Dies ist eine O(1)-Operation, ohne Kopieren und ohne massenhafte Änderungen an Metadaten.
Aus Sicht der Betriebseinführung ist der Aufwand minimal. Es reicht aus, hostUsers: false im Pod-Spec anzugeben. Container-Images und Build-Pipelines erfordern keine Änderungen. Das Verhalten bleibt mit den vorherigen Alpha- und Beta-Phasen kompatibel. Eine Einschränkung ist die Unterstützung nur für Linux, da der Mechanismus von den Fähigkeiten des Kernels abhängt.
Das Ergebnis ist ein sichereres Ausführungsmodell, ohne zu vollständig privilegierten Containern überzugehen. Szenarien, in denen früher der privilegierte Modus erforderlich war, können nun mit lokalisierten Rechten umgesetzt werden. Dies verringert das Risiko von lateral movement bei einer Kompromittierung. Quantitative Metriken in den Ausgangsdaten sind nicht angegeben, aber der Schlüsselfaktor ist die Beseitigung des kostspieligen chown und die Verbesserung der Startzeit für zustandsbehaftete Workloads.