fsGroup vs supplementalGroups-CodePudding

I'm running my deployment on OpenShift, and found that I need to have a GID of 2121 to have write access.

I still don't seem to have write access when I try this:

security:
  podSecurityContext: 
    fsGroup: 2121

This gives me a 2121 is not an allowed group error.

However, this does seem to be working for me:

security:
  podSecurityContext: 
    fsGroup: 100010000  # original fsGroup value 
    supplementalGroups: [2121]

I am wondering what the difference of fsGroup and supplementalGroups is.

I've read the documentation here: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems and have also looked at kubectl explain deployment.spec.template.spec.securityContext, but I still can't quite understand the difference.

Could I get some clarification on what are the different use cases?

CodePudding user response：

FSGroup is used to set the group that owns the pod volumes. This group will be used by Kubernetes to change the permissions of all files in volumes, when volumes are mounted by a pod.

The owning GID will be the FSGroup

The setgid bit is set (new files created in the volume will be owned by FSGroup)

The permission bits are OR'd with rw-rw----

If unset, the Kubelet will not modify the ownership and permissions of any volume.

Some caveats when using FSGroup:

Changing the ownership of a volume for slow and/or large file systems can cause delays in pod startup.
This can harm other processes using the same volume if their processes do not have permission to access the new GID.

SupplementalGroups - controls which supplemental group ID can be assigned to processes in a pod.

A list of groups applied to the first process run in each container, in addition to the container's primary GID. If unspecified, no groups will be added to any container.

Additionally from the OpenShift documentation:

The recommended way to handle NFS access, assuming it is not an option to change permissions on the NFS export, is to use supplemental groups. Supplemental groups in OpenShift Container Platform are used for shared storage, of which NFS is an example. In contrast, block storage such as iSCSI uses the fsGroup SCC strategy and the fsGroup value in the securityContext of the pod.