Kubernetes 1.31: Precise Control Over Group Memberships in Pods

Kubernetes 1.31 introduces an exciting new feature that enhances the handling of group memberships in containers within Pods. This change aims to refine control over group memberships and minimize potential security risks.

What Specifically Changes for Developers/DevOps Teams?

With the introduction of the new supplementalGroupsPolicy field in a Pod’s .spec.securityContext, the way group memberships for container processes are calculated is optimized. Developers and DevOps teams now have the option to choose between two policies:

• Merge: The group memberships defined in /etc/group for the primary user of the container are merged. This is the default option and ensures backward compatibility.
• Strict: Only the specified group IDs in the fsGroup, supplementalGroups, or runAsGroup fields are appended as group memberships for container processes. Group memberships from /etc/group are ignored.

Practical Examples or Use Cases

Let’s assume we have a Pod that defines runAsUser=1000, runAsGroup=3000, and supplementalGroups=4000 in the security context. Here’s an example of how to create a Pod with the default policy:

apiVersion: v1
kind: Pod
metadata:
  name: implicit-groups
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups:
      - 4000
  containers:
  - name: my-container
    image: my-image

Create the Pod with: console $ kubectl apply -f https://k8s.io/blog/2024-08-22-Fine-grained-SupplementalGroups-control/implicit-groups.yaml

Check that the Pod is running: console $ kubectl get pod implicit-groups

Execute the id command in the container to see the group memberships: console $ kubectl exec implicit-groups – id

The output should look similar to: none uid=1000 gid=3000 groups=3000,4000,50000

The group 50000 comes from the /etc/group file in the container image.

If you want to use the Strict policy, the Pod manifest might look like this:

apiVersion: v1
kind: Pod
metadata:
  name: strict-supplementalgroups-policy
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroupsPolicy: Strict
    supplementalGroups:
      - 4000
  containers:
  - name: my-container
    image: my-image

Create the Pod with: console $ kubectl apply -f https://k8s.io/blog/2024-08-22-Fine-grained-SupplementalGroups-control/strict-supplementalgroups-policy.yaml

These new capabilities for controlling group memberships are particularly important for security policies and access management in Kubernetes. ayedo, as your partner for Kubernetes, is happy to support you in implementing these new features and help you operate your applications securely and efficiently.

Source: Kubernetes Blog