<p><strong>Description</strong></p>
<p>I have a kubernetes pod with <code>initContainer</code> that requires to run as privileged (<code>privileged: true</code>). The second container (not init) does not require such privileges.</p>
<p>I want to enable <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/" rel="nofollow noreferrer">PodSecurityPolicy</a> admission plugin and I was searching for possibility to have different privileges/capabilities for different containers inside the pod.</p>
<p>I'm quite sure that it doesn't follow any best practice, but I'm just wondering if this is any close to possible. Maybe I'm misunderstanding some concepts?</p>
<p><strong>Question</strong></p>
<p>Do you know if there is a way to define PodSecurityPolicy for specific container inside a pod?</p>

<p>First and foremost take a notice on all know the theory of kubernetes pod security policy best practices:</p>
<ul>
<li>Do not run privileged containers.</li>
<li>Do not run containers as root.</li>
<li>Do not allow access to the host namespace.</li>
<li>Restrict Linux capabilities.</li>
</ul>
<p>In a Kubernetes pod, containers can optionally run in “privileged” mode, which means that the processes inside the container have almost unrestricted access to resources on the host system. While there are certain use cases where this level of access is necessary, in general, it’s a security risk to let your containers do this.
Please take a look: <a href="https://containerjournal.com/topics/container-security/establishing-a-kubernetes-pod-security-policy/" rel="nofollow noreferrer">pod-sp</a>, <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#privileged" rel="nofollow noreferrer">pod-psp-privileged</a>.</p>
<p>There are some proposal for refactoring <code>SecurityContext</code> to have pod-level and container-level attributes in order to correctly model pod- and container-level security concerns.</p>
<p>For an example, you may want to have a pod with two containers, one of which runs as root with the privileged setting, and one that runs as a non-root UID.
Here is an example:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: container-1
    securityContext:
      privileged: true
  - name: container-2
    securityContext:
      runAsUser: 1002
</code></pre>
<p>See more: <a href="https://stupefied-goodall-e282f7.netlify.app/contributors/design-proposals/auth/pod-security-context/" rel="nofollow noreferrer">security-context-example</a>.</p>
<p>To specify security settings for a Container, include the <code>securityContext</code> field in the Container manifest. The <code>securityContext</code> field is a <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#securitycontext-v1-core" rel="nofollow noreferrer">SecurityContext</a> object. Security settings that you specify for a Container apply only to the individual Container, and they override settings made at the Pod level when there is overlap. Container settings do not affect the Pod's Volumes.</p>
<p>But for now it is not possible to create one PodSecurityContext for different containers.securityContext.</p>
<p>Instead of giving the pod/container root priviliged users should add to the specified containers linux only specific capabilities improving container isolation. Take a look: <a href="https://www.google.com/url?q=https://kubernetes.io/docs/tasks/configure-pod-container/security-context/%23set-capabilities-for-a-container&amp;sa=D&amp;source=hangouts&amp;ust=1603962258991000&amp;usg=AFQjCNFBvzYkJxwLIy5BgThZkHERyxf_5Q" rel="nofollow noreferrer">set-capabilities-for-a-container</a>.</p>
<p>With Linux capabilities, you can grant certain privileges to a process without granting all the privileges of the root user. To add or remove Linux capabilities for a Container, include the capabilities field in the securityContext section of the Container manifest.</p>
<p>In contrast to privileged processes that bypass all kernel permission checks, unprivileged processes have to pass full permission checking based on the process’s credentials such as effective UID, GID, and supplementary group list. Starting with kernel 2.2, Linux has divided privileged processes’ privileges into distinct units, known as capabilities. These distinct units/privileges can be independently assigned and enabled for unprivileged processes introducing root privileges to them. Kubernetes users can use Linux capabilities to grant certain privileges to a process without giving it all privileges of the root user. This is helpful for improving container isolation from the host since containers no longer need to write as root — you can just grant certain root privileges to them and that’s it.</p>
<p>To add or remove Linux capabilities for a container, you can include the capabilities field in the  <code>securityContext</code>  section of the container manifest. Let’s see an example:</p>
<pre class="lang-yaml prettyprint-override"><code>    apiVersion: v1  
    kind: Pod  
    metadata:  
      name: linux-capabilities-example 
    spec:  
      securityContext:  
        runAsUser: 3000  
      containers:  
      - name: linux-capabilities  
        image: supergiantkir/k8s-liveliness  
        securityContext:  
          capabilities:  
            add: [&quot;NET_ADMIN&quot;]
</code></pre>
<p>In this example,  <code>CAP_NET_ADMIN</code>  is assigned capability to the container. This Linux capability allows a process to perform various network-related operations such as interface configuration, administration of IP firewall, modifying routing tables, enabling multicasting, etc. For the full list of available capabilities, see the official  <a href="http://man7.org/linux/man-pages/man7/capabilities.7.html" rel="nofollow noreferrer">Linux documentation</a>.</p>
<p>Read more: <a href="https://medium.com/kubernetes-tutorials/defining-privileges-and-access-control-settings-for-pods-and-containers-in-kubernetes-2cef08fc62b7" rel="nofollow noreferrer">linux-capabilities</a>.</p>
