{"resourceId":"ieee-access-ebpf-security-tools-kubernetes-overhead-20250902","versions":[{"version":"external-3fc48dc8fe209e49c280e2f5d42424311717817d306240cb450d2e86131826fe","resource":{"id":"ieee-access-ebpf-security-tools-kubernetes-overhead-20250902","title":"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","organization":"Jin Her, Jongseop Kim, Jinwoo Kim, Seungsoo Lee (Incheon National University; Kwangwoon University)","sector":"Academic research / cloud-native security","geography":"Republic of Korea research; global applicability","publishedAt":"IEEE Access vol. 13, date of publication 2 September 2025 (DOI 10.1109/ACCESS.2025.3605432)","publicationDate":"2025-09-02","eventDate":null,"sourceName":"IEEE Access (author-hosted PDF)","sourceLabel":"An In-Depth Analysis of eBPF-Based System Security Tools in Cloud-Native Environments","sourceUrl":"https://cclab.info/papers/2025_her_access.pdf","evidenceClass":"academic-research","outcomeClass":"mixed","topics":["infrastructure","data-security"],"finding":"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.","sledRelevance":"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":"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.","architectureImplications":"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.","governanceImplications":"Interpretation: performance acceptance thresholds for runtime sensors should be set per workload class and recorded in change approvals.","securityPrivacyImplications":"Event loss under load and known eBPF evasion techniques mean runtime sensors should not be the only detection layer.","caveats":"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.","streamIds":["palo-alto-networks"],"roles":{"sales":"Sales framing: this neutral study helps set realistic expectations for any eBPF-based runtime sensor, including Palo Alto's new Cortex Cloud Sensor. It shows overhead can be small without policies and large once enforcement is on, especially for network-heavy workloads. Use it to propose a performance pilot rather than to argue for or against a product, and to show customers that performance claims will be tested on their workloads.","engineering":"Engineering framing: overhead in the study ranged from about 1.5% to nearly 89% depending on tool, workload and policy. Engineers should benchmark process-heavy and network-heavy workloads separately, with policies on and off, and check for event loss at peak. The listed eBPF limits (verifier, user-space integration, ring-buffer saturation, io_uring evasion) should shape detection layering so runtime sensors are not the only control.","delivery":"Delivery framing: use the study's benchmark design as a template for sensor acceptance tests on customer clusters. Platform engineering should own the measurements, with security reviewing detection coverage. Repeat tests after kernel or sensor upgrades. The main risk is assuming a vendor's relative resource claim holds for network-intensive research or public-facing services without measurement, then discovering latency or dropped events only after prevention policies are switched on in production."},"roleDetails":{"sales":{"customerProblem":"Platform teams fear runtime security sensors will slow workloads but lack neutral data on eBPF overhead.","stakeholders":["Platform engineering lead","Research computing director","CISO"],"discoveryQuestions":["Which workloads are network-intensive or latency-sensitive?","Have you measured overhead of any runtime sensor before?","What performance budget is acceptable?"],"valueHypothesis":"Grounding sensor selection in workload-specific tests can avoid both performance surprises and unprotected workloads.","potentialEngagement":"A runtime sensor benchmarking exercise modeled on the study's process and network tests.","unsupportedClaims":["Performance figures for the Cortex Cloud Sensor","That eBPF sensors are always lightweight","That eBPF monitoring cannot be evaded"]},"engineering":{"fit":"Applies to any eBPF runtime sensor decision on Kubernetes.","architectureIntegration":"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.","proofOfValue":["Replicate process and network benchmarks with policies on and off","Measure event loss at peak event rates"]},"delivery":{"work":"Build sensor performance acceptance tests per workload class.","dependencies":["Test environment","Platform team time"],"ownership":"Platform engineering, with security operations reviewing results.","skillsAdoption":"Teams need benchmarking and eBPF troubleshooting skills.","governanceCheckpoints":["Benchmark results reviewed before prevention mode","Re-test after kernel or sensor upgrades"],"acceptanceCriteria":["Proposed: overhead per workload class documented with repeated runs","Proposed: event loss measured at expected peak load"],"risks":["Unrepresentative benchmarks","Kernel upgrades changing performance"]}},"retrievedAt":"2026-11-11T03:51:10Z","enrichedAt":"2026-11-11T04:00:05Z","enrichmentBasis":"retrieved source","accessibilityWorkforceImplications":"Benchmarking and eBPF troubleshooting skills are scarce in many SLED teams; partners or training may be needed.","procurementImplications":"Interpretation: include workload-specific performance acceptance tests in runtime sensor contracts.","operatingModelImplications":"Performance testing should be repeated after kernel or sensor upgrades.","peerReview":"peer-reviewed","sourceVerification":{"openedUrl":"https://cclab.info/papers/2025_her_access.pdf","referenceExcerpt":"eBPF itself presents several inherent limitations: i) constraints imposed by the verifier, ii) limited integration with user-space security mechanisms","promptVersion":"sled-research-v4.0","model":null,"basis":"agent-reported inspection"}}}]}