kubernetes - 无法创建Pod沙箱:rpc错误:代码=未知desc =内核中未启用seccomp，无法与配置文件一起运行

Question

我在kube和Cri-o时遇到问题。
实际上，我正在部署kube集群，而只是不想部署仪表板。
我已经安装了CRIO而不是Docker(在生产环境中为RHEL8)。
“describe pod”命令的输出日志为:

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

我已经试过了: grep SECCOMP /boot/config-$(uname -r)

CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_SECCOMP=y

有了这些返回，我认为这已启用...

在安装kube的过程中，我在系统中找到了一个seccomp.json文件，我试图在CRI-O的config的 seccomp_profile部分中设置绝对路径，但没有...这不是解决方案.. 。

有谁有主意...？

问候，

Answer 1

Kubernetes仪表板部署yaml seccomp默认设置为seccomp.security.alpha.kubernetes.io/pod: 'runtime/default'
这意味着它正在使用默认的容器运行时配置文件，我们可以阅读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.

Unexpected behavior with empty seccomp profile有一个github问题。
在讨论中， @saschagrunert提到:

... 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

正如 @CptBuko所提到的，他通过设置 seccomp.security.alpha.kubernetes.io/pod: unconfined来为自己解决问题，该方法未将seccomp应用于容器进程。