Supplemental groups: remove unexpected access inherited from an image

Last updated: 1 Oct 20266 min read

tutorial

A container process can inherit supplementary groups from the image's account database in addition to groups declared in a Pod security context. Those extra groups may grant access to mounted files even when runAsUser and runAsGroup look narrow. SupplementalGroupsPolicy Strict limits the group set to explicit Pod choices on supported nodes and runtimes. Its availability varies by Kubernetes and node runtime version, so mixed-node behavior must be checked before relying on it.

Operational decision

A receipt-index worker should read an archive volume as group 3047 and nothing else. Inspect the image's account record and the process identity in a canary Pod. Apply the fragment below in a compatible test cluster, confirm the node advertises support, then compare the first process's UID, primary GID, and supplementary groups with the intended set. Attempt reads of a permitted archive file and a decoy file owned by a group present only in the image. On older nodes or unsupported runtimes, verify whether the Pod is rejected or whether the intended rule is not enforced; do not silently keep using the same manifest. Keep the volume's fsGroup behavior separate from the process group calculation, because a mount permission change can also affect access. If the application performs its own setgroups call, test the effective identity after startup, not only the initial Pod status.

securityContext:
  runAsUser: 2047
  runAsGroup: 2047
  fsGroup: 3047
  supplementalGroupsPolicy: Strict

Cost and verification

Strict groups can expose image assumptions and cause permission errors that were masked by an undeclared image group. Fix the image or file ownership rather than adding broad groups until tests pass. Measure unexpected group memberships, denied file reads, and Pod start failures by node runtime. This Pod-level fragment needs a supported cluster and volume-permission review before deployment; the same group number can carry different business meaning in another workload.

Common Mistakes

Do not infer the full process group set from runAsUser alone.
Do not assume every node supports Strict or has the same fallback behavior.
Do not add a broad group solely to silence an access failure without checking the file owner.

Connected lessons

Practice and check

devops

operations