<p>I'm running my deployment on OpenShift, and found that I need to have a GID of 2121 to have write access.</p>
<p>I still don't seem to have write access when I try this:</p>
<pre><code>security:
  podSecurityContext: 
    fsGroup: 2121
</code></pre>
<p>This gives me a <code>2121 is not an allowed group</code> error.</p>
<p>However, this does seem to be working for me:</p>
<pre><code>security:
  podSecurityContext: 
    fsGroup: 100010000  # original fsGroup value 
    supplementalGroups: [2121]
</code></pre>
<p>I am wondering what the difference of <code>fsGroup</code> and <code>supplementalGroups</code> is.</p>
<p>I've read the documentation <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems" rel="nofollow noreferrer">here</a> and have also looked at <code>kubectl explain deployment.spec.template.spec.securityContext</code>, but I still can't quite understand the difference.</p>
<p>Could I get some clarification on what are the different use cases?</p>

Kun Hwi Ko
<p><code>FSGroup</code> 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.</p>
<blockquote>
<ol>
<li><p>The owning GID will be the FSGroup</p>
</li>
<li><p>The setgid bit is set (new files created in the volume will be owned by FSGroup)</p>
</li>
<li><p>The permission bits are OR'd with rw-rw----</p>
<p>If unset, the Kubelet will not modify the ownership and permissions of
any volume.</p>
</li>
</ol>
</blockquote>
<p>Some caveats when using <code>FSGroup</code>:</p>
<ul>
<li><p>Changing the ownership of a volume for slow and/or large file systems
can cause delays in pod startup.</p>
</li>
<li><p>This can harm other processes using the same volume if their
processes do not have permission to access the new GID.</p>
</li>
</ul>
<p><code>SupplementalGroups</code> - controls which supplemental group ID can be assigned to processes in a pod.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Additionally from the <a href="https://docs.openshift.com/container-platform/4.9/storage/persistent_storage/persistent-storage-nfs.html#storage-persistent-storage-nfs-group-ids_persistent-storage-nfs" rel="noreferrer">OpenShift documentation</a>:</p>
<blockquote>
<p>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.</p>
</blockquote>
