From the Palo Alto Networks edition of November 10, 2026
IEEE Access study of four eBPF security tools on Kubernetes finds overhead varies sharply by tool and policy, and flags eBPF verifier, log-loss and evasion limits
Jin Her, Jongseop Kim, Jinwoo Kim, Seungsoo Lee (Incheon National University; Kwangwoon University) · Academic research / cloud-native security · Republic of Korea research; global applicability
- Publisher
- IEEE Access (author-hosted PDF)
- Original publication
- IEEE Access vol. 13, date of publication 2 September 2025 (DOI 10.1109/ACCESS.2025.3605432)
- Source retrieved
- 2026-11-11
What happened
The peer-reviewed study compares KubeArmor, Falco, Tetragon and Tracee on Kubernetes. In a process benchmark (running /usr/bin/ls 10,000 times, 10 iterations), overhead ranged from about 6.88% (Tetragon, no policy) to 37.59% (Tracee with policy). In a network benchmark of 100,000 UDP packets, overhead ranged from 1.48% (Tracee, no policy) to 88.59% (KubeArmor with policy), and Tetragon rose from 3.14% to 72.92% once a policy was enabled. The authors note trade-offs between enforcement speed and log loss, and list inherent eBPF limits: verifier constraints, weak integration with user-space controls, kernel-to-user bottlenecks that can drop events under load, and evasion via io_uring or avoiding standard syscall paths. AI-driven eBPF security platforms were out of scope.
Why it matters
Why now: Palo Alto's Nov. 10 Cortex Cloud Sensor relies on eBPF and claims up to 75% fewer resources than its standard sensor. This study gives SLED platform teams (state data centers, research clusters) an independent baseline showing overhead depends on workload type and policy, so they should test before committing. Transferability caveat: Korean university lab study of open-source tools, not U.S. public-sector production systems.
Evidence and measured results
Opened the author-hosted PDF and read the benchmark methods, results, insights and limitations sections. ANOVA results are reported with very small p-values. Commercial products, including Palo Alto's, were not tested.
Limitations and uncertainty
Tests open-source tools on micro-benchmarks, not the Cortex Cloud Sensor; results may not transfer to commercial sensors or real applications. Korean university research with a government grant; lab environment rather than production. Published 2025; included because it is newly relevant to the Nov. 10 sensor launch.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-11; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Platform teams fear runtime security sensors will slow workloads but lack neutral data on eBPF overhead.
- Stakeholders
- Platform engineering lead
- Research computing director
- CISO
- Discovery questions
- Which workloads are network-intensive or latency-sensitive?
- Have you measured overhead of any runtime sensor before?
- What performance budget is acceptable?
- Value hypothesis
- Grounding sensor selection in workload-specific tests can avoid both performance surprises and unprotected workloads.
- Potential engagement
- A runtime sensor benchmarking exercise modeled on the study's process and network tests.
- Unsupported claims
- Performance figures for the Cortex Cloud Sensor
- That eBPF sensors are always lightweight
- That eBPF monitoring cannot be evaded
Pre-sales engineering
Role takeaway
- Fit
- Applies to any eBPF runtime sensor decision on Kubernetes.
- Architecture and integration
- Benchmark method for DaemonSet-based sensors; informs policy scope and monitor versus enforce modes.
- Prerequisites
- Test cluster mirroring production kernels
- Load generation tools
- Baseline metrics without sensor
- Constraints
- Lab micro-benchmarks may not reflect real apps
- Commercial sensors not tested
- Security
- Layer runtime sensors with other detections because of log-loss and evasion limits.
- Proof of value
- Replicate process and network benchmarks with policies on and off
- Measure event loss at peak event rates
Delivery
Role takeaway
- Work
- Build sensor performance acceptance tests per workload class.
- Dependencies
- Test environment
- Platform team time
- Ownership
- Platform engineering, with security operations reviewing results.
- Skills and adoption
- Teams need benchmarking and eBPF troubleshooting skills.
- Governance checkpoints
- Benchmark results reviewed before prevention mode
- Re-test after kernel or sensor upgrades
- Acceptance criteria
- Proposed: overhead per workload class documented with repeated runs
- Proposed: event loss measured at expected peak load
- Risks
- Unrepresentative benchmarks
- Kernel upgrades changing performance
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Network-heavy workloads and enforced policies drive the largest overheads; architects should profile by workload class and consider monitor-only modes for latency-sensitive services.
Governance
Who approves, reviews and stays accountable for outcomes?
Performance acceptance thresholds for runtime sensors should be set per workload class and recorded in change approvals.
Security and privacy
What data, permissions and controls need testing?
Event loss under load and known eBPF evasion techniques mean runtime sensors should not be the only detection layer.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Benchmarking and eBPF troubleshooting skills are scarce in many SLED teams; partners or training may be needed.
Procurement
What should contracts, pricing and exit terms secure?
Include workload-specific performance acceptance tests in runtime sensor contracts.
Operating model
Which teams own the service once it runs?
Performance testing should be repeated after kernel or sensor upgrades.
Publication history
- 2026-11-10Palo Alto Networks · Issue 117 resources
Stable resource ID: ieee-access-ebpf-security-tools-kubernetes-overhead-20250902