Benutzer-Namensräume: Stateful Pods jetzt in Kubernetes 1.28 verfügbar!

Kubernetes v1.25 führte die Unterstützung von Benutzer-Namensräumen nur für stateless Pods ein. Mit Kubernetes 1.28 wurde diese Einschränkung aufgehoben, nachdem in der Version 1.27 einige Designänderungen vorgenommen wurden.

Die Schönheit dieser Funktion liegt darin, dass:

• sie mühelos übernommen werden kann (man muss nur ein boolesches Feld in der Pod-Spezifikation setzen)
• keine Änderungen für die meisten Anwendungen erforderlich sind
• die Sicherheit drastisch verbessert wird, indem die Isolation von Containern erhöht und CVEs mit den Bewertungen HOCH und KRITISCH gemindert werden.

Dieser Beitrag erklärt die Grundlagen der Benutzer-Namensräume und zeigt:

• die Änderungen, die mit der aktuellen Kubernetes v1.28-Version eingeführt wurden
• eine Demonstration einer als HOCH bewerteten Sicherheitsanfälligkeit, die mit Benutzer-Namensräumen nicht ausgenutzt werden kann
• die Laufzeitanforderungen zur Nutzung dieser Funktion
• was Sie in zukünftigen Versionen in Bezug auf Benutzer-Namensräume erwarten können.

Was ist ein Benutzer-Namensraum?

Ein Benutzer-Namensraum ist ein Linux-Feature, das die Benutzer- und Gruppenidentifikatoren (UIDs und GIDs) der Container von denjenigen des Hosts isoliert. Die Identifikatoren im Container können so auf Identifikatoren auf dem Host abgebildet werden, dass sich die verwendeten Host-UIDs/GIDs für verschiedene Container niemals überschneiden. Darüber hinaus können die Identifikatoren auf unprivilegierte nicht-überlappende UIDs und GIDs auf dem Host abgebildet werden. Dies bedeutet im Wesentlichen zwei Dinge:

• Da die UIDs und GIDs für verschiedene Container auf unterschiedliche UIDs und GIDs auf dem Host abgebildet sind, haben Container es schwerer, einander anzugreifen, selbst wenn sie die Grenzen des Containers überschreiten. Wenn beispielsweise Container A mit anderen UIDs und GIDs auf dem Host läuft als Container B, sind die Operationen, die es auf den Dateien und Prozessen von Container B durchführen kann, eingeschränkt: Es kann nur lesen/schreiben, was eine Datei für andere erlaubt, da es niemals die Berechtigung für den Eigentümer oder die Gruppe haben wird (die UIDs/GIDs auf dem Host sind garantiert unterschiedlich für verschiedene Container).

• Da die UIDs und GIDs auf unprivilegierte Benutzer auf dem Host abgebildet sind, hat ein Container, der die Grenzen des Containers überschreitet, selbst wenn er als root innerhalb des Containers läuft, keine Berechtigungen 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 gew granted capabilities nur innerhalb des Benutzer-Namensraums gültig und nicht auf dem Host.

Ohne die Verwendung eines Benutzer-Namensraums hat ein Container, der als root läuft, im Fall eines Container-Breakouts root-Rechte auf dem Knoten. Und wenn dem Container einige Berechtigungen gewährt wurden, sind diese Berechtigungen auch auf dem Host gültig. Nichts davon trifft zu, wenn Benutzer-Namensräume verwendet werden (außer bei Bugs, natürlich 🙂).

Änderungen in 1.28

Wie bereits erwähnt, unterstützt Kubernetes ab Version 1.28 Benutzer-Namensräume mit Stateful Pods. Das bedeutet, dass Pods mit Benutzer-Namensräumen jeden Typ von Volume verwenden können und nicht mehr auf einige Volumenarten beschränkt sind wie zuvor.

Das Feature-Flag zur Aktivierung dieser Funktion wurde umbenannt. Es heißt nicht mehr UserNamespacesStatelessPodsSupport, sondern ab 1.28 sollten Sie UserNamespacesSupport verwenden. Es wurden viele Änderungen vorgenommen und die Anforderungen an die Knoten-Hosts haben sich geändert. Das Feature-Flag wurde umbenannt, um dies widerzuspiegeln.

Die ayedo GmbH unterstützt Sie gerne bei der Implementierung und Nutzung von Kubernetes und den neuen Funktionen wie Benutzer-Namensräumen, um Ihre Anwendungen sicherer und flexibler zu gestalten.

Quelle: Kubernetes Blog