K
Q

Failed to create pod sandbox: rpc error: code = Unknown desc = seccomp is not enabled in your kernel, cannot run with a profile

4/6/2020

I'm having a problem with kube & 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 :

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

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

CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_SECCOMP=y

With these returns I think this is enabled ...

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

Does anyone have an idea ...?

Regards,

-- CptBuko
cri-o
kubernetes
seccomp

Similar Questions

Unable to deploy helm chart on remote kubernetes server using org.unbroken-dome.helm plugin
Alert kubernetes deployments not healthy GCP
How to rollback data when perform release rollback from prod?
Enable IAP on Ingress

1 Answer

4/21/2020

Kubernetes Dashboard Deployment yaml the seccomp by default is set to seccomp.security.alpha.kubernetes.io/pod: 'runtime/default'

This means it's using default container runtime profile which we can read here

The use of seccomp profiles in pods can be controlled via annotations on the PodSecurityPolicy. Seccomp is an alpha feature in Kubernetes.

seccomp.security.alpha.kubernetes.io/defaultProfileName - Annotation that specifies the default seccomp profile to apply to containers. Possible values are:

  • unconfined - Seccomp is not applied to the container processes (this is the default in Kubernetes), if no alternative is provided.
  • runtime/default - The default container runtime profile is used.
  • docker/default - The Docker default seccomp profile is used. Deprecated as of Kubernetes 1.11. Use runtime/default instead.
  • localhost/<path> - Specify a profile as a file on the node located at <seccomp_root>/<path>, where <seccomp_root> is defined via the --seccomp-profile-root flag on the Kubelet.

There is a github issue for Unexpected behavior with empty seccomp profile. In the discussion @saschagrunert mentions:

... Generally it was not possible for me to find any generalized description of:

  • If a profile is specified to a pod, it applies to all containers as well
    (only supported by seccomp right now)
  • If a profile is specified to a container, it overwrites the pods profile
  • We always default to runtime/default

I really would like to enforce this from a security perspective and document it properly in a dedicated security section inside this repository. WDYT?

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: https://kubernetes.io/docs/tutorials/clusters/apparmor/#upgrade-path-to-general-availability

As already mentioned by @CptBuko, he manged a workaround for himself by setting seccomp.security.alpha.kubernetes.io/pod: unconfined which is not applying seccomp to the container processes.

-- Crou
Source: StackOverflow