Skip to content

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.

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

Synchronous Blocking Supported

These distributions cover approximately 95% of production Kubernetes deployments.

Distribution Kernel Notes
Ubuntu 18.04+ 4.15+ Enabled by default since 2018. Covers GKE, EKS, AKS default node images
Debian 10+ (Buster) 4.19+ Enabled by default
Amazon Linux 2 / 2023 EKS-optimized AMIs Enabled
Google Container-Optimized OS (COS) GKE default Enabled
Flatcar Container Linux -- Enabled
Fedora CoreOS -- Enabled
Bottlerocket (AWS) -- Enabled
RHEL 9 / CentOS Stream 9 / Rocky 9 / Alma 9 5.14+ Enabled

Synchronous Blocking Not Supported

These distributions fall back to reactive kill + audit logging. Listed in order of market importance.

Distribution Kernel Why Mitigation
RHEL 7 / CentOS 7 3.10 Kernel too old for kprobe override EOL June 2024. Reactive kill + audit logging
RHEL 8 / CentOS 8 / Rocky 8 / Alma 8 4.18 Red Hat explicitly disabled CONFIG_BPF_KPROBE_OVERRIDE in their kernel config Most common enterprise gap. Reactive kill + audit
SUSE Linux Enterprise Server (SLES) 15 -- Disabled in default kernel config Reactive kill + audit
Oracle Linux with UEK Varies Some UEK builds disable it Check with zcat /proc/config.gz \| grep BPF_KPROBE_OVERRIDE
Custom / hardened kernels Varies Security-focused distros may strip it Verify kernel config before deployment

RHEL 8 is the most common gap

Red Hat explicitly disabled CONFIG_BPF_KPROBE_OVERRIDE in RHEL 8's kernel configuration. If you are running OpenShift on RHEL 8, CloudTaser will use reactive kill instead of synchronous blocking. Upgrading to RHEL 9 / OpenShift on RHEL 9 enables synchronous blocking.

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

On a running node:

zcat /proc/config.gz 2>/dev/null | grep CONFIG_BPF_KPROBE_OVERRIDE

grep CONFIG_BPF_KPROBE_OVERRIDE /boot/config-$(uname -r)

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}'

Expected output for supported kernels:

CONFIG_BPF_KPROBE_OVERRIDE=y

Agent Behavior at Startup

The agent logs its enforcement mode at startup:

{"level":"INFO","msg":"eBPF agent started","enforce_mode":true,"kprobes_active":true}
  • kprobes_active: true -- synchronous blocking active, zero data leakage
  • kprobes_active: false -- tracepoint detection + reactive kill (SIGKILL)

When kprobes fail to load, the agent logs a warning and continues:

{"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}

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.