Kubernetes v1.35: Fine-grained Supplemental Groups Control Graduates to GA

Kubernetes v1.35: Fine-grained Supplemental Groups Control Graduates to GA On behalf of Kubernetes SIG Node, we are pleased to announce the graduation of fine-grained supplemental groups control to General Availability (GA) in Kubernetes v1.35! The new Pod field, supplementalGroupsPolicy , was introduced as an opt-in alpha feature for Kubernetes v1.31, and then had graduated to beta in v1.33. Now, the feature is generally available. This feature allows you to implement more precise control over supplemental groups in Linux containers that can strengthen the security posture particularly in accessing volumes. Moreover, it also enhances the transparency of UID/GID details in containers, offering improved security oversight. If you are planning to upgrade your cluster from v1.32 or an earlier version, please be aware that some behavioral breaking change introduced since beta (v1.33). For more details, see the behavioral changes introduced in beta and the upgrade considerations sections of the previous blog for graduation to beta. Motivation: Implicit group memberships defined in /etc/group in the container image Even though the majority of Kubernetes cluster admins/users may not be aware of this, by default Kubernetes merges group information from the Pod with information defined in /etc/group in the container image. Here's an example; a Pod manifest that specifies spec.securityContext.runAsUser: 1000 , spec.securityContext.runAsGroup: 3000 and spec.securityContext.supplementalGroups: 4000 as part of the Pod's security context. apiVersion: v1 kind: Pod metadata: name: implicit-groups-example spec: securityContext: runAsUser: 1000 runAsGroup: 3000 supplementalGroups: [4000] containers: - name: example-container image: registry.k8s.io/e2e-test-images/agnhost:2.45 command: [ "sh", "-c", "sleep 1h" ] securityContext: allowPrivilegeEscalation: false What is the result of id command in the example-container container? The output should be similar to this: uid=1000 gid=3000 groups=3000,4000,50000 Where does group ID 50000 in supplementary groups ( groups field) come from, even though 50000 is not defined in the Pod's manifest at all? The answer is /etc/group file in the container image. Checking the contents of /etc/group in the container image contains something like the following: user-defined-in-image:x:1000: group-defined-in-image:x:50000:user-defined-in-image This shows that the container's primary user 1000 belongs to the group 50000 in the last entry. Thus, the group membership defined in /etc/group in the container image for the container's primary user is implicitly merged to the information from the Pod. Please note that this was a design decision the current CRI implementations inherited from Docker, and the community never really reconsidered it until now. What's wrong with it? The implicitly merged group information from /etc/group in the container image poses a security risk. These implicit GIDs can't be detected or validated by policy engines because there's no record of them in the Pod manifest. This can lead to unexpected access control issues, particularly when accessing volumes (see kubernetes/kubernetes#112879 for details) because file permission is controlled by UID/GIDs in Linux. Fine-grained supplemental groups control in a Pod: supplementaryGroupsPolicy To tackle this problem, a Pod's .spec.securityContext now includes supplementalGroupsPolicy field. This field lets you control how Kubernetes calculates the supplementary groups for container processes within a Pod. The available policies are: Merge : The group membership defined in /etc/group...

Preview: ~500 words