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

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


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.