<p>I have enabled podsecuritypolicy in minikube. By default it has created two psp - privileged and restricted.</p>
<pre><code>NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
restricted   false          RunAsAny   MustRunAsNonRoot   MustRunAs   MustRunAs   false            configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim
</code></pre>
<p>I have also created a linux user - kubexz, for which I have created ClusterRole and RoleBinding to restrict for only managing pods on kubexz namespace, and use the restricted psp.</p>
<pre><code>apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: only-edit
rules:
- apiGroups: [&quot;&quot;]
  resources: [&quot;pods&quot;]
  verbs: [&quot;create&quot;, &quot;delete&quot;, &quot;deletecollection&quot;, &quot;patch&quot;, &quot;update&quot;, &quot;get&quot;, &quot;list&quot;, &quot;watch&quot;]
- apiGroups: [&quot;policy&quot;]
  resources: [&quot;podsecuritypolicies&quot;]
  resourceNames: [&quot;restricted&quot;]
  verbs: [&quot;use&quot;]
</code></pre>
<pre><code>apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: kubexz-rolebinding
  namespace: kubexz
subjects:
   - kind: User
     name: kubexz
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: only-edit
</code></pre>
<p>I have set the kubeconfig file in my kubexz user $HOME/.kube. The RBAC is working fine - From kubexz user I am only able to create and manage pod resources in the kubexz namespace as expected.</p>
<p>But when I post a pod manifest with <code>securityContext.privileged: true</code>, the restricted podsecuritypolicy is not stopping me to create that pod. I should not be able to create a pod with privilege container. But the pod is getting created. Not sure what am I missing</p>
<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: new-pod
spec:
  hostPID: true
  containers:
  - name: justsleep
    image: alpine
    command: [&quot;/bin/sleep&quot;, &quot;999999&quot;]
    securityContext:
      privileged: true
</code></pre>

<p>I have followed PodsecurityPolicy using minikube.
<em><strong>This work by default only while using Minikube 1.11.1 with Kubernetes 1.16.x or higher</strong></em>.</p>
<blockquote>
<p><a href="https://minikube.sigs.k8s.io/docs/tutorials/using_psp/#older-versions-of-minikube" rel="nofollow noreferrer">Note for older versions of minikube</a>:</p>
<p><strong>Older versions of minikube do not ship with the pod-security-policy addon</strong>, so the policies that addon enables must be separately applied to the cluster</p>
</blockquote>
<p>What I did:</p>
<p><strong>1</strong>. Start minikube with the PodSecurityPolicy admission controller and the pod-security-policy addon enabled.</p>
<pre><code>minikube start --extra-config=apiserver.enable-admission-plugins=PodSecurityPolicy --addons=pod-security-policy
</code></pre>
<blockquote>
<p>The pod-security-policy addon must be enabled along with the admission controller to prevent issues during bootstrap.</p>
</blockquote>
<p><strong>2</strong>. Create  <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/" rel="nofollow noreferrer">authenticated user</a>:</p>
<blockquote>
<p>In this regard, Kubernetes does not have objects which represent normal user accounts. Normal users cannot be added to a cluster through an API call.</p>
<p>Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, <strong>Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”)</strong>. From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource.</p>
</blockquote>
<p><a href="https://www.infracloud.io/blogs/role-based-access-kubernetes/" rel="nofollow noreferrer">Here</a> you can find example how you can properly prepare X509 Client Certs and configure KubeConfig file accordingly.</p>
<p>The most important part is to define properly the <strong>common name (CN)</strong> and the <strong>organization field (O)</strong>:</p>
<pre><code>openssl req -new -key DevUser.key -out DevUser.csr -subj &quot;/CN=DevUser/O=development&quot;
</code></pre>
<blockquote>
<p>The common name (CN) of the subject will be used as username for authentication request. The organization field (O) will be used to indicate group membership of the user.</p>
</blockquote>
<hr />
<p>Finally I have created your configuration based on standard minikube setup and can't recreate your issue either due to <code>hostPID: true</code> or <code>securityContext.privileged: true</code></p>
<p>To consider:</p>
<p><strong>a</strong>). Verify if your <strong>client certificate for authentication</strong> and <a href="https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#define-clusters-users-and-contexts" rel="nofollow noreferrer">kubeconfig</a> file were created/setup properly especially common name (CN) and organization field (O).</p>
<p><strong>b</strong>). Make sure you are switching between proper context while performing requests on behalf of different users.</p>
<pre><code>   f.e. kubectl get pods --context=NewUser-context 
</code></pre>
