Defend for Containers (D4C) integration with OPENSHIFT

Elastic Security
,
1

I am looking for some insight into a hard kernel verifier rejection we are hitting with the Defend for Containers (D4C) integration.

The Activity & Purpose We are deploying Elastic Agent (9.4.2) via Fleet on an OpenShift cluster to utilize eBPF-based container runtime security and active syscall blocking. The underlying nodes are running Amazon Linux 2023 (Kernel 6.1.174-217.345.amzn2023.x86_64).
What We Got (The Issue) The Elastic Agent DaemonSet deploys successfully, registers with Fleet, and components like Filebeat/Metricbeat are completely healthy. However, the cloud_defend component immediately crash-loops with the following status:

Failed: Startup error: load bpf progs (please ensure required Linux capabilities are set in k8s security context. BPF, PERFMON, and SYS_RESOURCE are mandatory): bpf-sensor errored

Diagnostic Steps Taken We have exhaustively ruled out Kubernetes-level permission issues:

  • Capabilities: The pod security context explicitly adds BPF, PERFMON, SYS_RESOURCE, and SYS_ADMIN.
  • SELinux: Running with seLinuxOptions: type: unconfined_t (and tested with spc_t).
  • Mounts: All required host paths (/proc, /sys/fs/bpf, /sys/kernel/debug, /boot, /sys/kernel/security) are mounted correctly.
  • Host Kernel: cat /sys/kernel/security/lsm confirms bpf is active.
  • Audit Logs: We temporarily raised the host audit_backlog_limit to 8192. dmesg confirms BPF-LSM is attached, but the kernel's eBPF Verifier is permanently rejecting the pre-compiled bytecode from the Elastic Agent.

is there any way to make this integration success??

2

Hello Mohamed_Nada, thank you for your question and the effort running d4c. Great that you use 9.4.2 version, because we have fixed some issues there.

Could you check for VERIFIER ERROR in the logs, just before the error message you have shared? If you have it, could you share the error message and the actual kernel version from this node?

What potentially could be is the additional security level your environment has. Could you check, if your k8s environment allows running privileged pods and elastic-agent with d4c is one of them? IIURC you would need to add privileged: true to the container security context.

Last but not least, have you tried to deploy default cloud-defend policy?

All in all, additional info would help to figure out what is going on. Feel free to open a support case.