<p>The K8s documentation has an example for a restricted PodSecurityPolicy:</p>
<p><a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#example-policies" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/policy/pod-security-policy/#example-policies</a></p>
<p>It restricts 'supplementalGroups' and 'fsGroup' but not 'runAsGroup'</p>
<pre><code>  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
</code></pre>
<p>Therefore it allows a container in the securityContext to specify the root group with id 0. Isn't this a problem? Shouldn't the following</p>
<pre><code>  runAsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
</code></pre>
<p>be added to a restrictive PodSecruityPolicy?</p>

<blockquote>
<p>Shouldn't the following...be added to a restrictive PodSecruityPolicy?</p>
</blockquote>
<p>It's an option to restrict your <a href="https://www.cyberciti.biz/faq/howto-linux-add-user-to-group/" rel="nofollow noreferrer">primary group</a>, if you don't have it then your primary group will not be restricted. So basically, pods can still run containers as the root <code>Group: 0</code>.</p>
<p><code>supplementalGroups</code> means any additional group added to the user besides the primary group (secondary groups). In *nix systems 🖥️ you can have a process run as belonging to a <a href="https://askubuntu.com/questions/538130/what-is-the-difference-between-primary-group-and-secondary-group-in-ubuntu">primary group and a set of limited secondary groups</a>.</p>
<p>✌️</p>
