<p>I am coming from Windows OS background and have limited knowledge on Linux.</p>
<p>As per the Microsoft documentation</p>
<blockquote>
<p>For your applications to run correctly, pods should run as a defined user or group and not as root. The securityContext for a pod or container lets you define settings such as runAsUser or fsGroup to assume the appropriate permissions. Only assign the required user or group permissions, and don't use the security context as a means to assume additional permissions. The runAsUser, privilege escalation, and other Linux capabilities settings are only available on Linux nodes and pods.</p>
</blockquote>
<p>and they provided the below sample</p>
<pre><code>kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    fsGroup: 2000
  containers:
    - name: security-context-demo
      image: nginx:1.15.5
      securityContext:
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          add: [&quot;NET_ADMIN&quot;, &quot;SYS_TIME&quot;]
</code></pre>
<p>Based on the given description, I understood that pod is not given root access and given limited access on network &amp; time.</p>
<p>What does <code>runAsUser: 1000</code> &amp; <code>fsGroup: 2000</code> mean? How to setup the <code>fsGroup</code>?</p>

One Developer
<p><code>runAsUser: 1000</code> field specifies that for any Containers in the Pod, all processes run with user ID <code>1000</code></p>
<p><code>fsGroup: 2000</code>  specifies all processes of the container are also part of the supplementary group ID <code>2000</code>.This group ID is associated with the <code>emptyDir</code> volume mounted in the pod and with any files created in that volume. You should remember that only certain volume types allow the kubelet to change the ownership of a volume to be owned by the pod. If the volume type allows this (as <code>emptyDir</code> volume type) the owning group ID will be the <code>fsGroup</code>.</p>
<p>One thing to remember with <code>fsGroup</code> is that when you try to mount a folder from your host. As Docker mounts the host volume preserving UUID and GUID from the host, permission issues in the Docker volume are possible. The user running the container may not have the appropriate privileges to write in the volume.</p>
<p>Possible solutions are running the container with the same UUID and GUID as the host or change the permissions of the host folder before mounting it to the container.</p>
<p>For more details on <code>fsGroup</code> refer to <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems" rel="nofollow noreferrer">docs</a></p>
