Kernel Compatibility¶
cloudtaser's eBPF agent provides three layers of runtime enforcement, each with different kernel requirements. The agent automatically detects kernel capabilities at startup and uses the strongest available mechanism.
Summary
cloudtaser's eBPF agent works on all major managed Kubernetes services (GKE, EKS, AKS) with full synchronous blocking. The main gap is RHEL 8 / OpenShift on RHEL 8, which falls back to reactive kill mode. Both modes provide complete audit trails for compliance. Upgrading to RHEL 9 enables full protection.
Enforcement Layers¶
| Layer | Mechanism | Kernel Requirement | Guarantee |
|---|---|---|---|
| Synchronous block | Kprobes + bpf_override_return() |
CONFIG_BPF_KPROBE_OVERRIDE=y |
Syscall returns -EACCES before any data is read |
| Reactive kill | Agent sends SIGKILL on detection | Any BPF-capable kernel (4.15+) | Process terminated (small race window) |
| Detection + audit | Tracepoints | Any BPF-capable kernel (4.15+) | Event logged with full context |
When kprobe override is available, cat /proc/<pid>/environ returns "Permission denied" with zero data leakage. When it is not available, the agent falls back to reactive kill (SIGKILL after detection) and always logs the access attempt.
Kernel Support Matrix¶
Per-distro kprobe-override capability¶
Use this as your architect-review checklist. For each node OS in your cluster, look up the version and confirm the enforcement mode you will get. Where a cell is marked ?, verify on a live node using the commands below.
| Distro / Node OS | Version | CONFIG_BPF_KPROBE_OVERRIDE |
Enforcement mode | Notes |
|---|---|---|---|---|
| Container-Optimized OS (GCP) | all LTS milestones (m101+) | no | lsm | GKE default. Covers >95% of production GKE. Kprobe override is not supported on COS; BPF LSM provides synchronous blocking for primary vectors, ReactiveKill covers secondary vectors |
| Bottlerocket (AWS / on-prem) | 1.19+ | yes | synchronous | EKS + Karpenter default on recent AMIs |
| Ubuntu (generic kernel) | 22.04+ | yes | synchronous | AKS default; also common on self-managed EKS/GKE |
| Ubuntu (generic kernel) | 20.04 | no | reactive | Focal ships the option disabled in the stock generic kernel. Upgrade to 22.04 for synchronous |
| Ubuntu (hwe kernel) | 20.04 + linux-generic-hwe-20.04 |
yes | synchronous | Enabling the HWE stack pulls a 5.15+ kernel with the option |
| Debian | 12 (Bookworm) | yes | synchronous | Kernel 6.1+ |
| Debian | 11 (Bullseye) | yes | synchronous | Kernel 5.10 backport |
| Amazon Linux 2 | default (kernel 4.14) | no | reactive | Upgrade to AL2023 or pin the 5.10 kernel variant for synchronous |
| Amazon Linux 2 | 5.10 kernel variant | yes | synchronous | amazon-linux-extras install kernel-5.10 |
| Amazon Linux 2023 | all | yes | synchronous | EKS-optimized AL2023 AMIs |
| RHEL 9 / Rocky 9 / Alma 9 / CentOS Stream 9 | all | yes | synchronous | Kernel 5.14+ |
| RHEL 8 / Rocky 8 / Alma 8 / CentOS Stream 8 | all | no | reactive | Red Hat explicitly disabled the option in RHEL 8's kernel config. Most common enterprise gap. Fixed by upgrading to RHEL 9 / OpenShift on 9 |
| RHEL 7 / CentOS 7 | all | no | reactive | EOL June 2024. Kernel 3.10 is too old regardless |
| SUSE SLES 15 | SP4 and earlier | ? (verify) | likely reactive | SUSE historically disables the option in stock kernel builds. Confirm on your node before ruling it in |
| SUSE SLES 15 | SP5+ | ? (verify) | may be synchronous | Some SP5 rebases re-enabled the option; check on a live node |
| Oracle Linux (UEK) | R6 / R7 | ? (verify) | varies | UEK rebases change kernel config; check each UEK release |
| Flatcar Container Linux | current stable | yes | synchronous | Tracks upstream mainline |
| Fedora CoreOS | current stable | yes | synchronous | Tracks Fedora kernel |
| Talos Linux | 1.5+ | yes | synchronous | Kernel 6.1+ |
| Alpine (node OS) | all | no | reactive | Alpine's linux-lts kernel ships without CONFIG_BPF_KPROBE_OVERRIDE. Also relevant: Alpine is uncommon as a K8s node OS (vs. as a container base image) |
| Custom / hardened kernels (LKRG, grsecurity, strict CI builds) | -- | ? (verify) | varies | Security-focused distros often strip the option. Always verify the config |
Two most common enterprise gaps
- RHEL 8 / OpenShift on RHEL 8 -- Red Hat explicitly disables
CONFIG_BPF_KPROBE_OVERRIDEin their kernel config. Fixed by upgrading to RHEL 9. - Ubuntu 20.04 generic -- shipped the option disabled. Fixed by upgrading to 22.04, or by installing the 20.04 HWE stack (
apt install linux-generic-hwe-20.04).
Both fall back to reactive kill + full audit logging. The compliance posture (audit trail) is identical; the difference is whether a data read is prevented pre-return or killed post-return.
CI-Validated Kernel Matrix¶
Every commit to cloudtaser-ebpf runs the full test suite against the following kernels. If your node OS appears in this table, the enforcement layer has been exercised against a kernel from the same lineage.
| Kernel | Version tested | Real-world mapping | Enforcement mode |
|---|---|---|---|
| GKE Container-Optimized OS | 6.12.55 | GKE default node image (COS milestone 121+) | Synchronous |
| Debian Bookworm | 6.1.166 | AKS default; self-managed clusters on Debian 12 | Synchronous |
| GKE Ubuntu | 6.8.0-1042-gke | GKE Ubuntu node image | Synchronous |
| RHEL 9 / Rocky 9 / Alma 9 | 5.14.0-427.el9 | OpenShift 4.14+; self-managed RHEL 9 clusters | Synchronous |
| Pre-BPF-LSM baseline | 5.4.290 | Older cloud VM kernels; reactive-kill coverage baseline | Reactive |
| Generic cloud (5.15 LTS) | 5.15.209 | Ubuntu 22.04 generic; linux-lts distributions |
Synchronous |
| Generic cloud (6.1 LTS) | 6.1.175 | Debian 12 / Ubuntu 22.04 HWE; EKS AL2023 | Synchronous |
| Generic cloud (6.6 LTS) | 6.6.142 | Ubuntu 24.04; recent Flatcar / Talos | Synchronous |
| Generic cloud (6.12 LTS) | 6.12.92 | Ubuntu 24.10+; mainline rolling | Synchronous |
The pre-BPF-LSM kernel (5.4.x) is included to validate graceful degradation: the agent loads, detects that bpf_override_return is unavailable, and falls back to reactive kill without crashing or blocking pod startup.
Kernel versions advance with each cloudtaser-ebpf release
The exact patch versions above reflect the matrix at the time of the current release. The CI matrix is updated with each new cloudtaser-kernels tag. To see the kernel version pinned to any specific release, check the cloudtaser-kernels release assets in the Codeberg repo.
Managed Kubernetes Services¶
| Service | Default Node OS | Kprobe Override |
|---|---|---|
| GKE | Container-Optimized OS / Ubuntu | Supported |
| EKS | Amazon Linux 2 / 2023 | Supported |
| AKS | Ubuntu | Supported |
| OpenShift (RHEL 8) | RHEL 8 | Not supported -- reactive kill fallback |
| OpenShift (RHEL 9) | RHEL 9 | Supported |
| RKE2 / k3s | Depends on host OS | Check host kernel config |
How to Check¶
Check the kernel config (before or after installing cloudtaser)¶
On each node OS you plan to run, confirm what the kernel actually exposes. The distro table above is a planning hint; the kernel config on the running node is ground truth.
Expected for synchronous: CONFIG_BPF_KPROBE_OVERRIDE=y.
Any of # CONFIG_BPF_KPROBE_OVERRIDE is not set, empty output, or missing file → reactive mode.
Most RHEL-family kernels expose this; some COS / Bottlerocket / stripped custom kernels do not.
# Node has neither /boot/config-* nor /proc/config.gz
# Fall back to a runtime probe from a privileged pod
bpftool feature probe kernel 2>/dev/null | grep -i kprobe_override
Requires bpftool in the probing pod (ship via a debug image) and host-pid + privileged.
# List every node and its kernel version -- useful for heterogeneous clusters
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\t"}{.status.nodeInfo.osImage}{"\n"}{end}'
Pair each row against the per-distro table above. Any row you cannot map → run one of the host-side checks.
Check what YOUR cluster is actually doing¶
Once cloudtaser is deployed, verify the enforcement mode is what you expect from the config check above -- don't infer from the distro alone.
Today (shipped) -- inspect the eBPF agent startup log:
kubectl logs -n cloudtaser-system -l app.kubernetes.io/name=cloudtaser-ebpf \
| grep -E '"msg":"eBPF agent started"'
Expected output:
kprobes_active: true→ synchronous blocking active, zero data leakage pre-return.kprobes_active: false→ tracepoint detection + reactive SIGKILL; audit logged.
When kprobes fail to load (distro in reactive column, or an unexpected config gap), the agent logs a warning first and keeps running:
{"level":"WARN","msg":"kprobe programs failed to load, retrying without enforcement","error":"...bpf_override_return..."}
{"level":"INFO","msg":"eBPF agent started","enforce_mode":true,"kprobes_active":false}
In a heterogeneous cluster (e.g. RHEL 9 + RHEL 8 mixed node pools), expect the log to differ per node. Aggregate with:
kubectl get pods -n cloudtaser-system -l app.kubernetes.io/name=cloudtaser-ebpf \
-o jsonpath='{range .items[*]}{.spec.nodeName}{"\t"}{.metadata.name}{"\n"}{end}' \
| while read node pod; do
mode=$(kubectl logs -n cloudtaser-system "$pod" \
| grep -oE '"kprobes_active":(true|false)' | head -1)
echo "$node $mode"
done
Roadmap -- Prometheus gauge:
A cloudtaser_ebpf_enforcement_mode{mode="synchronous|reactive", node="..."} gauge is on the roadmap (see Trust Chain observability metrics) and will make this scriptable without parsing logs. Until that lands, use the log grep above.
What to do if a node is in reactive mode¶
Not every distro cell is a blocker. Pick based on your threat model:
- Upgrade the node OS to a row with
yesin the per-distro table. Typical paths: Ubuntu 20.04 → 22.04; RHEL 8 → RHEL 9; Amazon Linux 2 (default) → AL2023 or the 5.10 kernel variant. - Move workloads to a separate node pool that runs a kprobe-override-capable distro (e.g. a Bottlerocket pool, RHEL 9 pool) and taint + nodeSelector your cloudtaser-protected workloads onto it. Note: GKE COS does not support kprobe override -- it gets synchronous blocking for primary vectors via BPF LSM instead (see the per-distro table above).
- Accept reactive mode. For GDPR / NIS2 / DORA compliance what matters is the audit trail, and reactive mode fully delivers that. See Compliance Implications below.
Compliance Implications¶
For GDPR, NIS2, and DORA compliance, what matters is the audit trail -- proof that access attempts are detected and recorded. Both enforcement modes (synchronous block and reactive kill) provide this.
The difference is operational:
| Synchronous Block | Reactive Kill | |
|---|---|---|
| Data leaked? | No | Possible (small race window) |
| Process killed? | No (syscall fails cleanly) | Yes (SIGKILL) |
| Audit event logged? | Yes | Yes |
| Compliance requirement met? | Yes | Yes |
Reactive kill is still effective in practice
The reactive kill race window is very small (microseconds between detection and SIGKILL). An attacker reading /proc/pid/environ gets killed before they can exfiltrate the data over the network, because the network send is also monitored and blocked.