# Defend for Containers (D4C) integration with OPENSHIFT

**URL:** <https://discuss.elastic.co/t/defend-for-containers-d4c-integration-with-openshift/387268>\
**Category:** Elastic Security\
**Tags:** docker, defend-for-containers\
**Created:** [June 24, 2026, 1:59pm UTC](https://discuss.elastic.co/t/defend-for-containers-d4c-integration-with-openshift/387268 "2026-06-24T13:59:50Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mohamed\_Nada](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mohamed_nada/32/147716_2.png) [@Mohamed\_Nada](https://discuss.elastic.co/u/Mohamed_Nada)\
**Post date:** [June 24, 2026, 1:59pm UTC](https://discuss.elastic.co/t/defend-for-containers-d4c-integration-with-openshift/387268/1 "2026-06-24T13:59:50Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Boris\_XDR](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/boris_xdr/32/147760_2.png) [@Boris\_XDR](https://discuss.elastic.co/u/Boris_XDR)\
**Post date:** [June 30, 2026, 1:31pm UTC](https://discuss.elastic.co/t/defend-for-containers-d4c-integration-with-openshift/387268/2 "2026-06-30T13:31:40Z")

</div>

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.