Kubernetes v1.33: Präzise Kontrolle über Gruppen für mehr Sicherheit

Die neue Funktion supplementalGroupsPolicy wurde als optionale Alpha-Funktion in Kubernetes v1.31 eingeführt und ist nun in v1.33 in die Beta-Phase übergegangen. Das zugehörige Feature Gate (SupplementalGroupsPolicy) ist jetzt standardmäßig aktiviert. Diese Funktion ermöglicht eine präzisere Kontrolle über die Supplemental Groups in Containern, was die Sicherheitslage insbesondere beim Zugriff auf Volumes stärkt. Zudem verbessert sie die Transparenz der UID/GID-Details in Containern und bietet somit eine verbesserte Sicherheitsüberwachung.

Bitte beachten Sie, dass diese Beta-Version einige Verhaltensänderungen beinhaltet. Weitere Informationen finden Sie in den Abschnitten Die eingeführten Verhaltensänderungen in der Beta und Upgrade-Überlegungen.

Motivation: Implizite Gruppenmitgliedschaften in /etc/group im Container-Image

Obwohl die meisten Kubernetes-Cluster-Administratoren und -Benutzer sich dessen möglicherweise nicht bewusst sind, fusioniert Kubernetes standardmäßig die Gruppendaten aus dem Pod mit den Informationen, die in /etc/group des Container-Images definiert sind.

Sehen wir uns ein Beispiel an: Das folgende Pod-Manifest spezifiziert runAsUser=1000, runAsGroup=3000 und supplementalGroups=4000 im Sicherheitskontext des Pods.

apiVersion: v1
kind: Pod
metadata:
  name: implicit-groups
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
  containers:
  - name: ctr
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

Was ist das Ergebnis des id-Befehls im ctr-Container? Die Ausgabe sollte ungefähr wie folgt aussehen:

none uid=1000 gid=3000 groups=3000,4000,50000

Woher kommt die Gruppen-ID 50000 in den Supplementary Groups (groups-Feld), obwohl 50000 im Pod-Manifest überhaupt nicht definiert ist? Die Antwort ist die Datei /etc/group im Container-Image.

Wenn wir den Inhalt von /etc/group im Container-Image überprüfen, sollte Folgendes angezeigt werden:

none user-defined-in-image:x:1000: group-defined-in-image:x:50000:user-defined-in-image

Dies zeigt, dass der primäre Benutzer des Containers 1000 in der letzten Zeile der Gruppe 50000 angehört.

Somit werden die in /etc/group im Container-Image definierten Gruppenmitgliedschaften für den primären Benutzer des Containers implizit mit den Informationen aus dem Pod zusammengeführt. Bitte beachten Sie, dass dies eine Designentscheidung war, die die aktuellen CRI-Implementierungen von Docker geerbt haben, und die Community sich bis jetzt nicht wirklich damit befasst hat.

Was ist daran problematisch?

Die implizit zusammengeführten Gruppeninformationen aus /etc/group im Container-Image stellen ein Sicherheitsrisiko dar. Diese impliziten GIDs können von Richtlinien-Engines nicht erkannt oder validiert werden, da es keinen Eintrag dafür im Pod-Manifest gibt. Dies kann zu unerwarteten Zugriffssteuerungsproblemen führen, insbesondere beim Zugriff auf Volumes (siehe kubernetes/kubernetes#112879 für Details), da die Dateiberechtigungen in Linux durch UID/GIDs gesteuert werden.

Mit der Einführung der supplementalGroupsPolicy in Kubernetes v1.33 haben Entwickler und DevOps-Teams nun die Möglichkeit, die Sicherheitslage ihrer Anwendungen zu verbessern und die Kontrolle über Gruppenmitgliedschaften zu optimieren. ayedo unterstützt Sie gerne dabei, diese neuen Funktionen effektiv in Ihre Kubernetes-Umgebung zu integrieren.

Quelle: Kubernetes Blog