Kubernetes v1.33: Precise Control Over Groups for Enhanced Security

The new supplementalGroupsPolicy feature was introduced as an optional alpha feature in Kubernetes v1.31 and has now moved to beta in v1.33. The associated feature gate (SupplementalGroupsPolicy) is now enabled by default. This feature allows for more precise control over Supplemental Groups in containers, strengthening the security posture, particularly when accessing volumes. Additionally, it improves the transparency of UID/GID details in containers, offering enhanced security monitoring.

Please note that this beta version includes some behavioral changes. For more information, refer to the sections The Introduced Behavioral Changes in Beta and Upgrade Considerations.

Motivation: Implicit Group Memberships in /etc/group in the Container Image

Although most Kubernetes cluster administrators and users may not be aware, Kubernetes merges group data from the Pod with the information defined in /etc/group of the container image by default.

Let’s look at an example: The following Pod manifest specifies runAsUser=1000, runAsGroup=3000, and supplementalGroups=4000 in the Pod’s security context.

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

What is the result of the id command in the ctr container? The output should look something like this:

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

Where does the group ID 50000 in the Supplementary Groups (groups field) come from, even though 50000 is not defined in the Pod manifest at all? The answer is the /etc/group file in the container image.

If we check the contents of /etc/group in the container image, it should show:

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

This shows that the primary user of the container 1000 belongs to the group 50000 in the last line.

Thus, the group memberships defined in /etc/group in the container image for the primary user of the container are implicitly merged with the information from the Pod. Please note that this was a design decision inherited from the current CRI implementations of Docker, and the community has not really addressed it until now.

What is problematic about this?

The implicitly merged group information from /etc/group in the container image poses a security risk. These implicit GIDs cannot be detected or validated by policy engines as there is no entry for them in the Pod manifest. This can lead to unexpected access control issues, especially when accessing volumes (see kubernetes/kubernetes#112879 for details), as file permissions in Linux are controlled by UID/GIDs.

With the introduction of supplementalGroupsPolicy in Kubernetes v1.33, developers and DevOps teams now have the opportunity to improve the security posture of their applications and optimize control over group memberships. ayedo is happy to assist you in effectively integrating these new features into your Kubernetes environment.

Source: Kubernetes Blog