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