💻 computer science

Runtime Detection of Attacks and Misconfigurations in Cloud-Native Kubernetes Environments Using eBPF Network Telemetry

This paper demonstrates that Hubble/eBPF network telemetry, when combined with carefully constructed ground-truth labels, can effectively detect runtime attacks and misconfigurations in Kubernetes environments, revealing that destination-side identity attributes are the strongest indicators of threats despite a trade-off between the high precision of rule-based detectors and the higher recall of Random Forest classifiers.

Original authors: Andrew Oppong-Asante, Bernard Kyiewu, Clinton Amponsah, Linda Bessa-Simons, Caleb Boakye Yiadom

Published 2026-06-25

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Andrew Oppong-Asante, Bernard Kyiewu, Clinton Amponsah, Linda Bessa-Simons, Caleb Boakye Yiadom

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a Kubernetes cluster as a massive, bustling office building where thousands of tiny, temporary workers (called containers) live and work. These workers are organized into different departments (called namespaces). In a secure building, there are strict rules: the accounting team can't wander into the server room, and the interns can't access the CEO's office.

However, sometimes the building managers make mistakes. They might leave doors unlocked, give everyone the master key, or let workers wear "super-suit" armor that lets them break walls. These mistakes are misconfigurations.

This paper is about building a super-powered security camera system to catch bad actors the moment they try to exploit these mistakes, without slowing down the building.

The Problem: Invisible Doors and Master Keys

The researchers started by intentionally making three specific mistakes in their test office building:

No Security Guards (Missing Network Policies): They removed the rules that stop workers from walking between departments. Now, anyone could walk anywhere.
Too Many Master Keys (Excessive RBAC): They gave a low-level worker a key that opened every door in the building, including the secret vault.
Super-Suits (Privileged Containers): They let a worker wear a suit that let them see and touch everything, even the building's foundation and electrical wiring.

Once these mistakes were in place, they sent in a "red team" (a group of ethical hackers) to try to break in, steal data, or jump from one department to another.

The Solution: The "eBPF" Super-Camera

To catch these intruders, the researchers didn't use a standard security camera. They used something called eBPF (extended Berkeley Packet Filter), which they describe as a super-advanced, high-speed sensor embedded directly into the building's plumbing and wiring.

This sensor, paired with a tool called Hubble, doesn't just take pictures; it records every single drop of water (data) flowing through the pipes. It knows exactly:

Who sent the drop (Source Pod).
Who received it (Destination Pod).
Which pipe it went through (Namespace).
What kind of drop it was (Port/Protocol).

The researchers collected over 3.8 million of these "flow records" (drops of data).

The Big Challenge: Sorting the Noise

Here is the tricky part: The camera recorded everything. Most of the time, the building was just doing normal work (benign traffic). The actual attacks were like finding a few needles in a haystack of 3 million pieces of hay.

Furthermore, the camera had a weird quirk. Sometimes it saw the water drop as it left the faucet (TO_STACK), sometimes as it hit the pipe (TO_ENDPOINT), and sometimes as it traveled through the main line (TO_OVERLAY).

The Problem: When the camera saw the drop at the "faucet" stage, it often couldn't see where it was going. It was like seeing a letter leave a mailbox but not knowing the address on the envelope.
The Fix: The researchers had to go through a rigorous four-step cleaning process to throw away the blurry, incomplete records and keep only the ones where they could clearly see the destination. This turned their 3.8 million messy records into a clean dataset of 3.18 million records, with only 456 confirmed "attack" records.

The Detectives: Rules vs. AI

The researchers tested two different ways to spot the bad guys in this clean data:

The Rule-Based Detective: This detective follows a strict checklist. "If a worker from the 'Attacker' department tries to talk to the 'Database' department on port 5432, sound the alarm!"
- Result: This detective was very precise. When it sounded the alarm, it was usually right. However, it missed some sneaky attacks that didn't fit its exact checklist.
The Random Forest (AI) Detective: This detective is like a student who has studied thousands of examples of normal and bad behavior. It looks at the whole picture and guesses, "This looks 80% like an attack."
- Result: This detective caught more of the bad guys (higher recall), but it also sounded the alarm a few times when it was just a normal worker doing something slightly unusual.

The Big Discovery: Who You Are Talking To Matters Most

The most surprising finding was about who the bad guys were trying to talk to.

The researchers found that the most important clues weren't about who sent the message, but who received it.

The Metaphor: It doesn't matter if a normal-looking person (Source) sends a letter. What matters is that they are trying to deliver it to the Bank Vault (Destination).
The Ratio: The "Destination" clues were 2.8 times more important than the "Source" clues. If a worker tries to talk to the database or the API server, that is a huge red flag, regardless of who they are.

The Conclusion

The paper concludes that using these high-speed sensors (eBPF/Hubble) works great for catching attacks in real-time, but only if you are very careful about how you label the data.

If you don't filter out the blurry records (where the destination is unknown), you can't tell the difference between a normal worker and a hacker. But if you do the cleaning correctly, you can build a system that spots intruders the moment they try to jump between departments or access the vault.

In short: You can catch the bad guys in a cloud office building, but you need a super-camera that knows exactly where the water is going, and you need to teach your security guards that where the message is going is more important than who sent it.

Technical Summary: Runtime Detection of Attacks and Misconfigurations in Cloud-Native Kubernetes Environments Using eBPF Network Telemetry

Problem Statement

Kubernetes has become the de facto standard for cloud-native workloads, yet its flexibility introduces a complex configuration surface prone to security risks. Misconfigurations such as missing NetworkPolicies, excessive Role-Based Access Control (RBAC) permissions, and privileged container execution create exploitable paths for lateral movement, unauthorized service access, and privilege escalation. While static analysis and pre-deployment hardening exist, they often fail to capture unsafe communication patterns that manifest only at runtime. Furthermore, existing runtime detection approaches frequently rely on system-call telemetry or generic network datasets that lack Kubernetes-specific context. A significant methodological gap remains in utilizing Hubble/eBPF network telemetry for security: the multi-observation-point architecture of Cilium (TO_STACK, TO_ENDPOINT, TO_OVERLAY) creates challenges in constructing reliable flow-level ground truth, as metadata completeness varies across these points.

Methodology

The study employs a reproducible experimental approach to address these challenges through the following steps:

Experimental Testbed: A four-node kind (Kubernetes-in-Docker) cluster running Kubernetes v1.35.0 was established. Cilium v1.16.6 was deployed as the Container Network Interface (CNI) with Hubble enabled for per-flow observability.
Workload and Namespace Design: The environment hosted a multi-tier microservice application distributed across five namespaces: frontend, backend, database, attacker, and monitoring.
Misconfiguration Injection: Three specific misconfiguration classes were introduced to enable attacks:
- M1 (Network Policy Absence): No NetworkPolicies deployed, allowing flat pod networking.
- M2 (Excessive RBAC): A service account in the attacker namespace was granted cluster-admin privileges.
- M3 (Privileged Runtime): A pod was configured with privileged: true, hostPath mounts, and elevated Linux capabilities.
Attack Scenarios: Four attack scenarios were executed against the misconfigured cluster:
- Attack A: Lateral movement via internal network scanning (nmap).
- Attack B: Repeated unauthorized database access attempts.
- Attack C: Host filesystem access via privileged containers.
- Attack D: RBAC abuse to enumerate cluster-wide secrets.
Telemetry Collection and Ground-Truth Resolution: Hubble captured per-flow JSON records. To address the ground-truth challenge posed by varying metadata completeness across observation points, a four-version ground-truth resolution process was applied:
- v1: Initial file-level labeling (overestimated attacks).
- v2: Removal of attacker-pod traffic (over-filtered, resulting in zero attacks).
- v3: Application of observation-point filtering and flow-level source-namespace logic.
- v4 (Final): Exclusion of attacker-pod communication with infrastructure namespaces (e.g., kube-system), resulting in a clean set of attack-origin flows.
Detection Framework: Two detectors were evaluated:
- Behavioral Rule-Based Detector: Defined rules for cross-namespace database access, lateral movement, and sensitive port scanning.
- Random Forest Classifier: Trained on Hubble-derived features (identities, ports, observation points, TCP flags) with balanced class weights.
Evaluation: Models were assessed using five-fold time-windowed cross-validation, prioritizing Precision-Recall analysis and Area Under the Precision-Recall Curve (AUPRC) due to severe class imbalance.

Key Contributions

Reproducible Testbed: Development of a four-node Kubernetes testbed instrumented with Cilium/Hubble, hosting a multi-tier application across five namespaces.
Validated Misconfigurations: Experimental injection and validation of three critical misconfiguration classes (absent NetworkPolicies, excessive RBAC, privileged execution) linked to real attack scenarios.
Labeled Dataset Construction: Creation of a dataset containing 3,180,125 labeled flows (456 attack-origin, 3,179,669 benign) derived from 3.8 million raw records, utilizing a documented four-version ground-truth resolution methodology to handle Cilium's multi-observation-point architecture.
Comparative Evaluation: A rigorous comparison of a rule-based detector and a Random Forest classifier using time-windowed cross-validation, feature importance analysis, and ablation testing.
Feature Importance Insight: Identification that destination-side identity attributes are the strongest discriminating signals in Kubernetes flow telemetry, exhibiting a destination-to-source importance ratio of 2.8:1.

Results

Dataset Characteristics: The final dataset contained 456 attack flows (0.014% of total), confirming extreme class imbalance. Attack flows were concentrated on PostgreSQL (5432), backend API (8080), and HTTP (80).
Observation Point Impact: No attack flows were labeled at the TO_STACK observation point due to incomplete destination metadata. All 456 attack flows were located at TO_ENDPOINT and TO_OVERLAY, where metadata was sufficient for attribution. A chi-square test confirmed a statistically significant association between observation points and attack labels ( $\chi^2 = 2610.1, p < 0.001$ ).
Detector Performance:
- Rule-Based Detector: Achieved a higher AUPRC (0.311) compared to the Random Forest (0.284), indicating superior precision at high-confidence operating points. However, it had a lower mean recall (0.746) than the Random Forest (0.833).
- Random Forest: Achieved a higher mean recall but with a lower AUPRC. It demonstrated broader coverage but produced more distributed probability scores.
Feature Importance: Destination-side attributes (dst_identity, dst_port, dst_namespace, dst_pod) accounted for 64.2% of total feature importance, with a destination-to-source ratio of 2.8:1. Ablation testing confirmed that removing destination namespace and pod features reduced AUPRC by 7.4%.
Rule Performance: The CROSS_NS_DB_ACCESS rule generated the most true positives (324) but also the most false positives (425). The LATERAL_MOVEMENT rule had higher precision (0.556) but very low recall (0.022).

Significance and Claims

The paper claims that Hubble/eBPF telemetry can effectively support runtime attack detection in Kubernetes environments, provided that the multi-observation-point architecture is handled with care. The study emphasizes that:

Ground-Truth Construction is Critical: Naïve labeling of Hubble data leads to inflated or incorrect attack classes. The proposed four-version resolution process is essential for creating reliable security datasets.
Destination Context is Key: Unlike generic network intrusion detection, Kubernetes attack detection relies heavily on destination-side identity attributes to distinguish malicious intent (e.g., a compromised pod accessing a database across namespaces).
Complementary Approaches: Rule-based and machine learning approaches offer complementary strengths; rules provide interpretable, high-precision alerts, while machine learning offers broader recall coverage.
Limitations: The authors modestly state that while results are promising, they are specific to the evaluated testbed. Generalizability to larger, diverse, multi-tenant production environments requires further validation. The study does not claim to solve all Kubernetes security issues but demonstrates the viability of flow-level eBPF telemetry for runtime detection when paired with rigorous data engineering.