Agents can't start on docker-driver minikube: securityfs (/sys/kernel/security) not mounted

[dorser]

Summary

micromize and sigward fail to start on a minikube cluster using the docker driver because securityfs is not mounted on the node, so /sys/kernel/security/lsm is missing.

Details

Both agents call utils.ValidateBPFLSM() at startup, which reads /sys/kernel/security/lsm and aborts if it's missing/empty. The Helm chart mounts the node's /sys/kernel/security into the pod — but the minikube node (a Docker container) has no securityfs mounted:

$ minikube ssh -- cat /sys/kernel/security/lsm
cat: /sys/kernel/security/lsm: No such file or directory
$ minikube ssh -- 'mount | grep -i security'      # (nothing)
$ minikube ssh -- 'ls /sys/kernel/security/'       # empty

This happens even though the host kernel has BPF-LSM enabled:

$ cat /sys/kernel/security/lsm     # on the host
lockdown,capability,yama,apparmor,bpf,ima,evm

Docker does not mount securityfs inside containers by default, so the minikube node — and therefore the agent pod that hostPath-mounts /sys/kernel/security — can't see it. A freshly created docker-driver minikube behaves the same way.

Impact

• Blocks running and e2e-testing micromize/sigward on docker-driver minikube.

Possible approaches (to decide later)

• Mount securityfs on the node before deploying: minikube ssh -- sudo mount -t securityfs securityfs /sys/kernel/security.
• Document the prerequisite in the dev/testing docs.
• Consider an optional privileged init step to mount securityfs (needs CAP_SYS_ADMIN; mounting from a pod is non-trivial).
• For CI/e2e, prefer host-based ig run (the existing tests/integration/ harness), where securityfs is available.

Environment

• minikube v1.32.0, docker driver, node kernel 6.17.0-1008-azure (Ubuntu 22.04)
• Host LSM: lockdown,capability,yama,apparmor,bpf,ima,evm

Discovered while setting up e2e tests covering all gadget event types (during the monorepo split work, PR #151).