Defend for containers integration failed on OpenShift environment

Elastic Security
1

kernel verifier rejection we are hitting with the Defend for Containers (D4C) integration.

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

Based on what you described, this no longer looks like a basic Kubernetes/OpenShift permission issue. The required Linux capabilities are already present, SELinux was tested with relaxed contexts, the host paths are mounted, and BPF-LSM is active. Elastic’s D4C requires Linux kernel 5.10.16+, CONFIG_BPF_LSM=y, CONFIG_SECURITY_PATH=y, CONFIG_DEBUG_INFO_BTF=y, and bpf in the LSM boot list.

Elastic also documents that D4C runs as an Elastic Agent DaemonSet and uses eBPF LSM plus tracepoint probes to evaluate container activity before allowing it to proceed. So if the kernel verifier is rejecting the pre-compiled BPF bytecode, the failure is probably at the kernel/eBPF compatibility layer, not Fleet registration or the Agent DaemonSet itself.

Amazon Linux 2023 is listed in Elastic’s managed Kubernetes support matrix for EKS, but this does not automatically mean that every OpenShift + AL2023 kernel build combination is validated. For self-managed Kubernetes clusters, Elastic says the node, operating system, and kernel must meet the D4C requirements.

I would validate these points directly on the affected node:

uname -a
grep -E 'CONFIG_BPF_LSM|CONFIG_SECURITY_PATH|CONFIG_DEBUG_INFO_BTF|CONFIG_BTF|CONFIG_BPF|CONFIG_BPF_SYSCALL' /boot/config-$(uname -r)
cat /sys/kernel/security/lsm
mount | grep -E 'bpf|debug|security'
dmesg -T | grep -iE 'bpf|verifier|cloud_defend|elastic|denied|reject'

If all requirements are confirmed and the verifier still rejects the program, I would open a support case or GitHub/docs issue with Elastic including:

Elastic Stack version: 9.4.2
Integration: Defend for Containers / cloud_defend
Kubernetes platform: OpenShift
Node OS: Amazon Linux 2023
Kernel: 6.1.174-217.345.amzn2023.x86_64
Container runtime: CRI-O or containerd
Full cloud_defend logs
Full dmesg verifier rejection output
DaemonSet securityContext
Output of /boot/config-$(uname -r)
Output of /sys/kernel/security/lsm

There may not be a manifest-side fix if this is a kernel verifier rejection against Elastic’s shipped eBPF program. The most practical next steps are: test the same Agent/D4C version on a kernel/platform explicitly validated by Elastic, test a different Elastic Agent/D4C package version if available, and ask Elastic engineering to confirm whether this specific Amazon Linux 2023 kernel build with OpenShift is supported or requires a product fix.