AppArmor Profile Loading on GKE COS failed with "open /proc/1/sched: no such file or directory"

[jindijamie]

What happened:

I was installing SPO and trying the AppArmor support on a GKE cluster with COS(Container-Optimized OS) nodes.
I applied the profile with
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/security-profiles-operator/refs/heads/main/examples/apparmorprofile.yaml

It failed with
E0924 21:11:54.292028 17496 apparmorprofile.go:116] "node \"gke-apparmor3-default-pool-1d3cb74c-fr7d\" does not support apparmor" err="profile not added" logger="apparmor-spod" apparmorprofile="test-profile" namespace="default"
And there is an error message at first
E0924 21:11:53.983973 17496 apparmorprofile.go:292] "mounting host" err="identifying pid namespace: open /proc/1/sched: no such file or directory" logger="apparmor-spod"
And I checked on the node, the file doesn't exist.

What you expected to happen:

The profile should be installed

How to reproduce it (as minimally and precisely as possible):

On a GKE COS cluster, install SPO.
kubectl -n security-profiles-operator patch spod spod --type=merge -p '{"spec":{"enableAppArmor":true}}'
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/security-profiles-operator/refs/heads/main/examples/apparmorprofile.yaml
Check the logs of the daemonset.

Anything else we need to know?:

I think it is similar to freeipa/freeipa#6453 and related to systemd/systemd#8153

Environment:

• Cloud provider or hardware configuration: GCP,
• OS (e.g: cat /etc/os-release): "Container-Optimized OS" VERSION_ID=109 BUILD_ID=17800.309.13
• Kernel (e.g. uname -a): Linux gke-apparmor2-default-pool-1a912e31-hlt3 6.1.100+ Implement minimal valuable implementation  #1 SMP PREEMPT_DYNAMIC Sat Aug 10 14:21:56 UTC 2024 x86_64 Intel(R) Xeon(R) CPU @ 2.20GHz GenuineIntel GNU/Linux
• Others:

[mhils]

E0924 21:11:53.983973   17496 apparmorprofile.go:292] "mounting host" err="identifying pid namespace: open /proc/1/sched: no such file or directory" logger="apparmor-spod"

This one is from here. Building the host kernel with CONFIG_SCHED_DEBUG=y is a workaround (but not a fix).

[ccojocar]

The spo currently unshare the fs namespace of the pid 1 from the container in order to reach the filesystem of the host, because it needs to convert the text based apparmor profile into the binary format and to load it into the kernel.

I think there are two possibilities here, either pid 1 is not accessible or is not available. For instance, in init containers this strategy doesn't work because they are not spawned as long running process.