<p>I want to check if pod in the cluster running as <code>privileged pods</code>, which can indicate that we may have security issue, so I check if
<code>privileged: true</code></p>
<p>However under the
<code>securityContext:</code> spec there is additional fields like</p>
<ul>
<li><code>allowPrivilegeEscalation</code></li>
<li><code>RunAsUser</code></li>
<li><code>ProcMount</code></li>
<li><code>Capabilities</code>
etc</li>
</ul>
<p>Which may be risky (not sure about it) ,</p>
<p>My question is in case the pod is marked as <code>privileged:false</code> and the other fields are true like the following example,if this indicate some security issue ? Does this pods can do some operation on <strong>other pods</strong> etc , access external data?</p>
<p><strong>For example</strong> the following configuration which indicate the the pod is not privileged but <code>allowPrivilegeEscalation: true</code></p>
<pre><code>securityContext:
  allowPrivilegeEscalation: true
  privileged: false
</code></pre>
<p>I want to know which <code>securityContext</code> combination of pod config can <strong>control other</strong> <code>pods/process</code> in the cluster ?</p>

<p>The <code>securityContext</code> are more related to the container itself and some access to the host machine.</p>
<p>The <code>allowPrivilegeEscalation</code> allow a process to gain more permissions than its parent process. This is more related to setuid/setgid flags in binaries, but inside a container there is no much to get worried about.</p>
<p>You can only control other containers in the host machine from inside a container if you have a <code>hostPath</code> volume, or something like that, allowing you to reach the <code>.sock</code> file as <code>/run/crio/crio.sock</code> or the <code>docker.sock</code>. Is pretty obvious that, if you are concerned about this, allowing requests to Docker API through the network should be disabled.</p>
<p>Of course, all of these access are ruled by DAC and MAC restrictions. This is why podman <strong>uidmap</strong> is better, because the root inside the container do not have the same root id outside the container.</p>
<p>From Kubernetes point of view, you don't need this kind of privileges, all you need is a <code>ServiceAccount</code> and the correct RBAC permissions to control other things inside Kubernetes. A <code>ServiceAccount</code> binded to a <code>cluster-admin</code> <code>ClusterRole</code> can do anything in the API and much more, like adding ssh keys to the hosts.</p>
<p>If you are concerned about pods executing things in Kubernetes or in the host, just force the use of <code>nonRoot</code> containers, avoid indiscriminate use of <code>hostPath</code> volumes, and control your RBAC.</p>
<p>Openshift uses a very nice restriction by default:</p>
<ul>
<li>Ensures that pods cannot run as privileged</li>
<li>Ensures that pods cannot mount host directory volumes</li>
<li>Requires that a pod is run as a user in a pre-allocated range of UIDs (openshift feature, random uid)</li>
<li>Requires that a pod is run with a pre-allocated MCS label (selinux related)</li>
</ul>
<p>I don't answer exactly what you want, because I shifted the attention to RBAC, but I hope this can give you a nice idea.</p>
