eBPF for Runtime Security: How Kernel-Level Monitoring Changes Everything
eBPF has transformed how we observe and secure running systems. By running sandboxed programs inside the Linux kernel without modifying kernel source or loading kernel modules, eBPF gives security tools visibility that was previously impossible without significant performance penalties. Here is what that means for runtime security.
What Is eBPF?
eBPF (extended Berkeley Packet Filter) started as a mechanism for efficient network packet filtering in the Linux kernel and evolved into a general-purpose in-kernel virtual machine. An eBPF program is a small, restricted piece of code written in a subset of C (or increasingly in Rust), compiled to eBPF bytecode, verified by the kernel's eBPF verifier for safety, and then JIT-compiled to native machine instructions and executed inside the kernel.
The Key Properties That Make eBPF Unique
Kernel-native execution
Runs inside the kernel for complete visibility into all system calls, network events, and process activity—without leaving kernel space.
Safety-verified
The eBPF verifier statically analyzes programs before loading them, preventing infinite loops, invalid memory access, and kernel panics.
No kernel modules
Unlike traditional kernel extensions, eBPF programs do not require loading kernel modules, which reduces security risk and eliminates kernel version compatibility issues.
Near-zero overhead
JIT compilation to native instructions means eBPF programs execute at near-native speed. Security monitoring adds less than 3% CPU overhead.
The eBPF ecosystem has grown dramatically since 2015. Cloudflare uses it for DDoS mitigation, Meta uses it for production profiling at scale, Google uses it in their GKE data plane, and the Linux networking stack uses it for XDP (eXpress Data Path) packet processing. For security, eBPF enables visibility that previously required intrusive userspace agents or custom kernel modules.
How eBPF Works for Security: Probes and Hooks
eBPF security tools attach programs to kernel hook points— specific locations in the kernel execution path where the eBPF program runs when that event occurs. For security monitoring, the most important hook types are:
kprobes / kretprobes
Attach to any kernel function entry or return point. Used to trace syscall handlers—the most fundamental unit of OS interaction.
execve() for process executionopenat() for file accessconnect() for network callssetuid() for privilege changesTracepoints
Stable, documented kernel hook points that survive kernel version changes. More reliable than kprobes for production use.
sys_enter_execvesys_enter_openatnet/net_dev_queuesched/sched_process_execLSM BPF Hooks
Linux Security Module hooks that allow eBPF programs to make security decisions—returning an error code to block an operation. Requires kernel 5.7+.
bprm_check_security (exec control)file_open (file access control)socket_connect (network control)task_fix_setuid (privilege control)When a process calls execve(), the kernel executes the syscall handler, which triggers any attached kprobes or tracepoints. The eBPF program runs, reads the process name, arguments, PID, UID, and cgroup information from kernel memory using the BPF helper functions, packages this into a perf event or ring buffer, and sends it to userspace. All of this happens in microseconds, before the child process starts executing.
eBPF vs. Traditional Security Agents
Traditional security agents (AV/EDR agents, HIDS like OSSEC, audit-based solutions) use different mechanisms to collect runtime data. Each approach has significant tradeoffs in overhead, coverage, reliability, and deployment complexity.
| Property | auditd | Userspace Agent | eBPF |
|---|---|---|---|
| CPU overhead | 5–15% | 10–30% | <3% |
| Kernel modules required | No | Often | No |
| Event latency | High (write to disk) | Medium | Microseconds |
| Tamper resistance | Low (disable auditd) | Low | High (kernel-resident) |
| Container awareness | No (host only) | Partial | Full (cgroup/namespace-aware) |
| Enforcement capability | None (log only) | Limited | Yes (LSM BPF) |
| Deployment complexity | Medium | High | Low (single binary) |
| Event completeness | Configurable (noisy) | Varies | Complete, low-noise |
eBPF Security Use Cases: What You Can Monitor and Enforce
Binary Execution Control
Monitor every process execution via execve probes. Record process name, arguments, parent PID, UID, and cgroup. Block unauthorized binaries with LSM BPF enforcement.
SOC 2 CC6.6, ISO 27001 A.8.7File Integrity Monitoring
Track reads and writes to critical paths (/etc/passwd, /etc/sudoers, /root, /var/log) via openat/write probes. Detect modifications in real time, not via periodic checksums.
SOC 2 CC6.1, ISO 27001 A.8.15Network Egress Monitoring
Intercept connect() and accept() syscalls to build a complete map of all network connections. Detect connections to unexpected external endpoints, C2 servers, or data exfiltration paths.
SOC 2 CC6.7, ISO 27001 A.8.20Privilege Escalation Detection
Monitor setuid, setgid, and capability change syscalls. Alert when a process unexpectedly acquires elevated privileges, detecting both legitimate escalations and attacks.
SOC 2 CC6.3, ISO 27001 A.8.18Secrets Exposure Detection
Detect when processes read from credential paths (/root/.aws/credentials, /.env, /proc/*/environ). Alerting on runtime secrets access catches leaks that static scanning misses.
SOC 2 CC6.1, ISO 27001 A.8.12Config Drift Detection
Monitor configuration file modifications at runtime. Detect unexpected changes to service configurations, cron jobs, and startup scripts that indicate tampering or misconfiguration.
SOC 2 CC8.1, ISO 27001 A.8.9LSM BPF for Active Enforcement: From Audit to Block
Monitoring is valuable, but enforcement is transformative. LSM BPF (Linux Security Module BPF), introduced in Linux 5.7, allows eBPF programs to hook into the Linux Security Module framework and return error codes that actively deny operations. This is how eBPF-based security moves from logging violations to preventing them.
Audit Mode
All operations are allowed to proceed. Security events are logged and sent to the telemetry collector. Used during the policy learning phase to understand normal behavior before enforcing restrictions.
- Zero disruption risk
- Builds behavioral baseline
- Identifies policy gaps
Enforce Mode
The LSM BPF hook returns -EPERM for operations that violate security policies. The kernel denies the syscall before it completes. Used in production once policies are tuned and verified.
- Blocks attacks in real time
- Enforces least privilege
- Kernel-level enforcement
The recommended approach is to run in audit mode for 1–2 weeks to collect behavioral data, then use that data to generate minimal-privilege allow-list policies, verify the policies in staging, and finally switch to enforce mode in production. This mirrors the approach used by tools like KubeArmor and Falco with policy enforcement.
Platform Support and Kernel Requirements
Monitoring Only
- kprobes / tracepoints
- perf events
- BPF maps
- Process, file, network monitoring
Monitoring + Enforcement
- All 4.15+ features
- LSM BPF hooks
- Active syscall blocking
- Policy enforcement
Full Feature Set
- All 5.7+ features
- BPF ring buffer (lower overhead)
- BTF CO-RE (portable BPF)
- Enhanced map types
Platform support across deployment environments:
- Kubernetes: Full support. Agent deployed as DaemonSet, inherits node kernel version. Works with EKS, GKE, AKS, and self-managed clusters.
- Docker: Full support. Agent runs on host, monitors all containers via cgroup namespace awareness.
- AWS ECS: Full support. Agent deployed as sidecar or host task. Detects ECS task metadata for enrichment.
- Bare metal / VMs: Full support. Systemd service deployment. Works on any Linux distribution with kernel 4.15+.
TigerGate's eBPF Agent: Runtime Security + Compliance Evidence
TigerGate's agent is a Go binary that loads libbpf-compiled C probes into the kernel to monitor eight security control categories (C1–C8). It runs in either audit or enforce mode, automatically detects the platform it is running on (Kubernetes, ECS, Docker, bare metal), enriches events with platform metadata, and streams them to the TigerGate Telemetry Collector via gRPC.
Performance Characteristics
- Less than 3% CPU overhead in production workloads
- Ring buffer for efficient kernel-to-userspace event transfer
- Configurable event sampling to reduce volume on high-traffic nodes
- BPF CO-RE for portable, kernel-version-independent probes
- Automatic reconnection to telemetry collector on network failures
Security Controls Monitored
- C1: Unauthorized binary execution (execve probes)
- C2: File integrity (openat/write/unlink on critical paths)
- C3: Log tampering (write operations on /var/log)
- C4: Network egress anomalies (connect/accept syscalls)
- C5: Privilege escalation (setuid/setgid/capabilities)
- C6: Secrets exposure (reads to credential paths)
- C7: Process behavior anomalies (unexpected child processes)
- C8: Config drift (writes to configuration files)
Deploy eBPF Runtime Security in Minutes
TigerGate's eBPF agent runs on Kubernetes, Docker, ECS, and bare metal with less than 3% CPU overhead. Deploy with a single command and get continuous runtime visibility and compliance evidence from day one.