Kubernetes 1.30: Mehr Sicherheit durch User-Namespace für Pods

Linux bietet verschiedene Namespaces, um Prozesse voneinander zu isolieren. Ein typischer Kubernetes-Pod läuft in einem Netzwerk-Namespace, um die Netzwerkidentität zu isolieren, und in einem PID-Namespace, um die Prozesse zu isolieren.

Ein Linux-Namespace, der bisher vernachlässigt wurde, ist der User Namespace. Dieser Namespace ermöglicht es uns, die Benutzer- und Gruppen-IDs (UIDs und GIDs), die wir innerhalb des Containers verwenden, von denen des Hosts zu isolieren.

Diese leistungsstarke Abstraktion erlaubt es uns, Container als “root” auszuführen: Wir sind root innerhalb des Containers und können alles tun, was ein root innerhalb des Pods tun kann. Unsere Interaktionen mit dem Host sind jedoch auf das beschränkt, was ein nicht privilegierter Benutzer tun kann. Dies ist großartig, um die Auswirkungen eines Container-Breakouts zu begrenzen.

Ein Container-Breakout ist, wenn ein Prozess innerhalb eines Containers durch eine nicht gepatchte Schwachstelle im Container-Laufzeitumfeld oder im Kernel auf den Host ausbrechen kann und somit auf Dateien auf dem Host oder andere Container zugreifen oder diese ändern kann. Wenn wir unsere Pods mit User-Namespaces ausführen, werden die Berechtigungen, die der Container über den Rest des Hosts hat, reduziert, und die Dateien außerhalb des Containers, auf die er zugreifen kann, sind ebenfalls begrenzt.

In Kubernetes v1.25 haben wir die Unterstützung für User-Namespaces nur für zustandslose Pods eingeführt. Kubernetes 1.28 hat diese Einschränkung aufgehoben, und jetzt, mit Kubernetes 1.30, bewegen wir uns in die Beta-Phase!

Was ist ein User Namespace?

Hinweis: Linux-User-Namespaces sind ein anderes Konzept als Kubernetes-Namensräume. Ersteres ist ein Feature des Linux-Kernels; letzteres ist ein Feature von Kubernetes.

User-Namespaces sind eine Linux-Funktion, die die UIDs und GIDs der Container von denen des Hosts isoliert. Die Identifikatoren im Container können so auf Identifikatoren auf dem Host abgebildet werden, dass die Host-UIDs/GIDs für verschiedene Container niemals überlappen. Darüber hinaus können die Identifikatoren auf nicht privilegierte, nicht überlappende UIDs und GIDs auf dem Host abgebildet werden. Dies bringt zwei wesentliche Vorteile:

• Verhinderung der lateralen Bewegung: Da die UIDs und GIDs für verschiedene Container auf unterschiedliche UIDs und GIDs auf dem Host abgebildet sind, haben Container es schwieriger, sich gegenseitig anzugreifen, selbst wenn sie die Container-Grenzen überschreiten. Angenommen, Container A läuft mit anderen UIDs und GIDs auf dem Host als Container B. In diesem Fall sind die Operationen, die er auf den Dateien und Prozessen von Container B durchführen kann, eingeschränkt: Er kann nur das lesen/schreiben, was die Datei anderen erlaubt, da er niemals die Berechtigungen des Eigentümers oder der Gruppe haben wird (die UIDs/GIDs auf dem Host sind garantiert unterschiedlich für verschiedene Container).

• Erhöhte Host-Isolation: Da die UIDs und GIDs auf nicht privilegierte Benutzer auf dem Host abgebildet sind, hat ein Container, der die Container-Grenzen überschreitet, selbst wenn er als root innerhalb des Containers läuft, keine Privilegien auf dem Host. Dies schützt erheblich, welche Host-Dateien er lesen/schreiben kann, welche Prozesse er Signale senden kann usw. Darüber hinaus sind die vergebenen Berechtigungen nur innerhalb des User-Namespace gültig und nicht auf dem Host, was die Auswirkungen eines Container-Breakouts begrenzt.

Ohne die Nutzung eines User-Namespace hätte ein Container, der als root läuft, im Falle eines Container-Breakouts root-Rechte auf dem Knoten. Wenn dem Container einige Berechtigungen gewährt wurden, sind diese auch auf dem Host gültig. Nichts davon trifft zu, wenn User-Namespaces verwendet werden (außer im Falle von Bugs, natürlich 🙂).

Durch die Einführung von User-Namespaces in Kubernetes 1.30 wird die Sicherheit und Isolation von Pods erheblich verbessert. Dies ist besonders wichtig für DevOps-Teams, die auf die Sicherheit ihrer Anwendungen und Daten achten müssen. Bei ayedo unterstützen wir Sie gerne als Partner bei der Implementierung dieser neuen Funktionalitäten!

Quelle: Kubernetes Blog