Non existing localhostProfile Seccomp profile is not applied on Kubernetes nodes >= 1.28 about kubernetes HOT 8 CLOSED

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

from kubernetes.

/sig node security

from kubernetes.

related pr #117050

issue #117045

from kubernetes.

/assign

from kubernetes.

hi @MetalPinguinInc , if you use containerd in k8s >= 1.28, you will still see error message:

cannot load seccomp profile

use contaienrd as coantienr runtime

minikube start --kubernetes-version=1.28.1 --container-runtime=containerd

I guess this is caused by different container runtimes, and your cri should be docker

from kubernetes.

hi @chengjoey on my own baremetal clusters I am indeed running Docker with containerd as the container runtime and cri-dockerd as a shim between Kubernetes and Docker.

I can indeed confirm that using containerd as the runtime directly, seems to correctly throw the error in minikube. This has left me confused. Without using the --container-runtime=containerd flag, both minikube start --kubernetes-version=1.28.1 and minikube start --kubernetes-version=1.27 report exactly the same docker versions:

> docker version
Client:
 Version:           24.0.7
 API version:       1.43
 Go version:        go1.20.10
 Git commit:        afdd53b
 Built:             Thu Oct 26 09:04:00 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.10
  Git commit:       311b9ff
  Built:            Thu Oct 26 09:05:28 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.7.8
  GitCommit:        8e4b0bde866788eec76735cc77c4720144248fb7
 runc:
  Version:          1.1.9
  GitCommit:        ccaecfcbc907d70a7aa870a6650887b901b25b82
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

I am slightly confused by the terminology here: Kubernetes can run on both Docker (in which case you also need cri-dockerd) and Containerd, but Docker uses containerd as its container runtime anyway. When I started using Kubernetes only Docker was used, is there any reason to still have docker in the mix or is this mostly still supported for backwards compatibility and is using containerd with kubernetes directly a more streamlined approach?

In anycase, could it be that the issue lies in how Kubernetes communicates security options to Docker in versions >= 1.28? Since the Docker version is the same between 1.28 and 1.27 it seems unlikely that this is a issue in Docker.

from kubernetes.

It sounds like this is an issue with cri-dockerd, not kubernetes. I'd be curious how cri-o handles it, but if you wish to keep using cri-dockerd and want this situation fixed, I recommend opening an issue with them.

/close

please reopen if you think there's something wrong with kubernetes :)

from kubernetes.

@haircommander: Closing this issue.

from kubernetes.