<p>I'm having a problem with kube &amp; Cri-o.
Actually I'm deploying a kube cluster and I just wan't to deploy the dashboard.
I've installed CRIO instead of Docker (RHEL8 in production environment).
The output log of the "describe pod" command is : </p>

<pre><code>Events:
  Type     Reason                  Age                 From                   Message
  ----     ------                  ----                ----                   -------
  Normal   Scheduled               11m                 default-scheduler      Successfully assigned kubernetes-dashboard/dashboard-metrics-scraper-6b4884c9d5-fwdv9 to worker-node1
  Warning  FailedCreatePodSandBox  95s (x48 over 11m)  kubelet, worker-node1  Failed to create pod sandbox: rpc error: code = Unknown desc = seccomp is not enabled in your kernel, cannot run with a profile
</code></pre>

<p>I've tried this :  <code>grep SECCOMP /boot/config-$(uname -r)</code></p>

<pre><code>CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_SECCOMP=y
</code></pre>

<p>With these returns I think this is enabled ... </p>

<p>During my install of kube, I found a seccomp.json file in my system, I've tried to set the absolut path in the <code>seccomp_profile</code> section in the CRI-O's config, but not ... It wasn't the solution ...</p>

<p>Does anyone have an idea ...? </p>

<p>Regards, </p>

<p>Kubernetes Dashboard Deployment <a href="https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml" rel="nofollow noreferrer">yaml</a> the seccomp by default is set to <code>seccomp.security.alpha.kubernetes.io/pod: 'runtime/default'</code></p>

<p>This means it's using default container runtime profile which we can read <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp" rel="nofollow noreferrer">here</a></p>

<blockquote>
  <p>The use of seccomp profiles in pods can be controlled via annotations on the PodSecurityPolicy. Seccomp is an alpha feature in Kubernetes.</p>
  
  <p><strong>seccomp.security.alpha.kubernetes.io/defaultProfileName</strong>  - Annotation that specifies the default seccomp profile to apply to containers. Possible values are:</p>
  
  <ul>
  <li><code>unconfined</code>  - Seccomp is not applied to the container processes (this is the default in Kubernetes), if no alternative is provided.</li>
  <li><code>runtime/default</code>  - The default container runtime profile is used.</li>
  <li><code>docker/default</code>  - The Docker default seccomp profile is used. Deprecated as of Kubernetes 1.11. Use  <code>runtime/default</code>  instead.</li>
  <li><code>localhost/&lt;path&gt;</code>  - Specify a profile as a file on the node located at  <code>&lt;seccomp_root&gt;/&lt;path&gt;</code>, where  <code>&lt;seccomp_root&gt;</code>  is defined via the  <code>--seccomp-profile-root</code>  flag on the Kubelet.</li>
  </ul>
</blockquote>

<p>There is a github issue for <a href="https://github.com/cri-o/cri-o/issues/3079" rel="nofollow noreferrer">Unexpected behavior with empty seccomp profile</a>.
In the discussion <a href="https://github.com/saschagrunert" rel="nofollow noreferrer">@saschagrunert</a> mentions:</p>

<blockquote>
  <p>...
  Generally it was not possible for me to find any generalized description of:</p>
  
  <ul>
  <li>If a profile is specified to a pod, it applies to all containers as well<br>
  (only supported by seccomp right now)</li>
  <li>If a profile is specified to a container, it overwrites the pods profile</li>
  <li>We always default to  <code>runtime/default</code></li>
  </ul>
  
  <p>I really would like to enforce this from a security perspective and document it properly in a dedicated security section inside this repository. WDYT?</p>
  
  <p>Btw, we should probably push for GA grauduation of seccomp and AppArmor to get a first class API inside the securityContext, like we have for SELinux. See:  <a href="https://kubernetes.io/docs/tutorials/clusters/apparmor/#upgrade-path-to-general-availability" rel="nofollow noreferrer">https://kubernetes.io/docs/tutorials/clusters/apparmor/#upgrade-path-to-general-availability</a></p>
</blockquote>

<p>As already mentioned by <a href="https://stackoverflow.com/users/13236838/cptbuko">@CptBuko</a>, he manged a workaround for himself by setting <code>seccomp.security.alpha.kubernetes.io/pod: unconfined</code> which is not applying seccomp to the container processes.</p>
