Die eBPF-Revolution: Sicherheit und Observability ohne Instrumentation

27. Februar 2026 | Lesezeit: 13 Minuten 37 Sekunden

Einleitung: Der Kernel als Infrastruktur

Jahrzehntelang bedeutete Observability, Code zu Ihren Anwendungen hinzuzufügen. Sie instrumentierten Ihre Services mit Metrics Libraries, sprenkten Tracing SDKs durch Ihre Call Paths und konfigurierten Log Shippers auf jedem Host. Jede Sichtkeitsebene kam mit einem Cost: Dependency Management, Performance Overhead, Code Changes, die deployed und maintained werden mussten. Verpassen Sie einen Endpoint und Sie hatten einen Blind Spot. Upgraden Sie eine Library und Sie riskierten, Ihre Telemetry Pipeline zu brechen.

eBPF ändert diese Gleichung grundsätzlich. Anstatt Anwendungen zu instrumentieren, instrumentieren Sie den Kernel. Jeder System Call, jedes Network Packet, jeder File Access, jede Process Execution durchlaufen den Linux Kernel — und eBPF lässt Sie auf diese Events observieren und handeln, ohne die Anwendungen zu modifizieren, die sie generieren. Zero Code Changes. Zero SDK Dependencies. Zero Deployment Coordination.

Das ist kein geringfügiger Verbesserung. Es ist eine andere Kategorie von Fähigkeit. Wenn Ihre Monitoring Layer auf Kernel-Ebene operiert, sehen Sie alles — einschließlich die Dinge, die Anwendungen nicht zu loggen wählen, die Network Connections, die Ihren Service Mesh umgehen und die Processes, die Ihr Container Runtime nicht weiß.

Das eBPF Ökosystem hat sich durch 2025 und in 2026 schnell gereift. Was einmal eine Sammlung von Research Projects und spezialisierten Tools war, ist zur Production Infrastructure at Scale geworden. Cilium handhabt Networking für Major Cloud Providers. Falco bietet Runtime Security für Kubernetes Clusters weltweit. Tetragon setzt Security Policies direkt im Kernel durch. Und Tools wie Coroot liefern Full-Stack Observability — Metrics, Logs, Traces und Continuous Profiling — von einem einzelnen eBPF-basiertem Agent, der Zero Application Changes erfordert.

Dieser Artikel erklärt, was eBPF ist, warum es für Sicherheit und Observability wichtig ist und wie man es praktisch adoptiert.

Was eBPF tatsächlich ist

eBPF steht für extended Berkeley Packet Filter, obwohl der Name zu diesem Punkt meist historisch ist. Modernes eBPF ist weit über Packet Filtering hinausgegangen.

Im Kern ist eBPF eine Virtual Machine innerhalb des Linux Kernel, der Sandboxed Programs als Antwort auf Kernel Events laufen lässt. Diese Programs können System Calls, Network Traffic, File Operations, Process Scheduling und im Wesentlichen jede Kernel-Level-Activity observieren — alles ohne den Kernel selbst zu modifizieren oder Kernel Modules zu erfordern.

Das Safety Model

Was eBPF praktisch macht, ist sein Safety Model. Bevor jede eBPF Program läuft, überprüft der Kernel Verifier sie erschöpfend:

Keine Unbounded Loops: Programs müssen enden. Der Verifier lehnt Programs ab, die indefinit laufen könnten.
Keine Invalid Memory Access: Jede Pointer Dereference wird validiert. Buffer Overflows sind unmöglich.
Stack Size Limits: Programs haben eine feste Stack Size (512 Bytes), was Stack Exhaustion verhindert.
Helper Function Access: Programs können nur vorgenehmigt Kernel Helper Functions anrufen, nicht willkürlich Kernel Code.
Privilege Requirements: eBPF Programs zu laden erfordert angepasste Capabilities (typischerweise CAP_BPF oder root).

Diese Überprüfung passiert zur Load Time, nicht zur Runtime. Sobald ein Program den Verifier passiert, läuft es bei Near-Native Speed ohne Runtime Safety Checks. Das Ergebnis ist Kernel-Level Observability mit vernachlässigbarem Performance Overhead — typischerweise weniger als 1-2% CPU Impact für umfassendes Monitoring.

Attachment Points

eBPF Programs attachen sich zu spezifischen Kernel Events, genannt Hooks oder Attachment Points:

Hook Type	Use Case	Beispiel
kprobes	Trace jede Kernel Function	Monitor `sys_open` zum File Access Tracking
tracepoints	Stable Kernel Trace Events	Track Process Creation via `sched_process_exec`
XDP	Network Packet Processing	Drop Malicious Packets vor sie Network Stack erreichen
TC	Traffic Control	Apply Network Policies auf Container Level
LSM	Linux Security Module Hooks	Enforce Security Policies auf File Operations
uprobe	User-Space Function Tracing	Profile Spezifische Application Functions
perf events	CPU Performance Counters	Continuous CPU und Memory Profiling

Die Breite der Attachment Points ist, was eBPF so mächtig macht. Ein einzelner eBPF-basierter Agent kann gleichzeitig Network Traffic, File Access, Process Execution, DNS Resolution und System Call Patterns monitoren — wobei eine Unified View bietet, die traditionell fünf oder sechs separate Tools erfordern würde.

eBPF für Observability: Alles sehen

Traditionelle Observability hat drei Säulen: Metrics, Logs und Traces. eBPF ermöglicht alle drei ohne Instrumentation und fügt ein viertes hinzu — Continuous Profiling — das mit Application-Level-Ansätzen unpraktisch ist.

Zero-Instrumentation Service Maps

Wenn eBPF Network Connections auf Kernel-Ebene monitort, sieht es jede TCP- und UDP-Verbindung zwischen Services — einschließlich Verbindungen, die Ihren Service Mesh, Sidecar Proxies oder Application-Level Instrumentation umgehen. Das ermöglicht automatische Service Discovery und Dependency Mapping.

Tools wie Coroot verwenden diese Fähigkeit, um Live Topology Maps zu generieren, die alle Service Dependencies zeigen. Keine Code Changes nötig. Keine Sidecar Container. Keine Per-Service-Konfiguration. Deploy den Agent und innerhalb von Minuten sehen Sie, welche Services mit welchen anderen kommunizieren, die Latency jeder Verbindung und die Error Rates über jeden Pfad.

Das ist besonders wertvoll für:

Legacy Applications, die ohne signifikante Effort nicht instrumentiert werden können
Third-Party Services, wo Sie den Code nicht kontrollieren
Polyglot Environments, wo verschiedene Services verschiedene Sprachen und Frameworks verwenden
Debugging Production Issues, wo unbekannte Dependencies kaskadierende Failures verursachen

Protocol-Aware Metrics

eBPF sieht nicht nur Network Connections — es versteht Protokolle. Durch Parsing Packet Headers auf Kernel-Ebene können eBPF Agents Application-Layer Metrics extrahieren ohne jedes Anwendungsbewusstsein:

HTTP/HTTPS: Request Method, Path, Status Code, Latency — äquivalent zu dem, das Sie aus einem Access Log bekommen würden, aber captured auf Kernel-Ebene für jeden Service automatisch.

Database Protokolle: PostgreSQL, MySQL, Redis und MongoDB Wire Protokolle werden geparst, um Query Latency, Error Rates und Connection Counts zu extrahieren. Das bedeutet, dass Sie Database Performance Metrics ohne Installation jedes Database Monitoring Agents oder Modifizierung Connection Strings bekommen.

gRPC: Method-Level Latency und Error Tracking für gRPC Services, captured ohne gRPC Framework Konfiguration zu modifizieren.

DNS: Resolution Latency und Failure Rates für jeden DNS Lookup, dabei helfen, DNS-bezogene Performance Issues zu identifizieren, die notorisch schwierig mit Application-Level Tools zu debuggen sind.

Kafka: Producer und Consumer Lag Messungen auf Protocol Level erfasst, wobei Broker-unabhängige Visibility in Message Pipeline Performance bietet.

Continuous Profiling

Vielleicht die am meisten untergeschätzte Fähigkeit von eBPF-basierter Observability ist Continuous Profiling. Traditionelles Profiling erfordert eine Profiler an einen spezifischen Process zu attachen, es für einen Zeitraum zu laufen und die Ausgabe zu analysieren. Das ist zu disruptive und resource-intensive für Production Use.

eBPF-basiertes Profiling funktioniert anders. Es attachet sich zu Perf Events und sampled CPU Stack Traces in Fixed Intervals über alle Processes auf einem Host. Der Overhead ist minimal — typischerweise weniger als 1% CPU — wobei es feasible wird, es kontinuierlich in Production zu laufen.

Der praktische Wert ist bedeutsam. Wenn ein Service eine Latency Spike erlebt, brauchen Sie nicht die Issue mit einem Profiler attached zu reproduzieren. Die Profiling Data ist bereits da, erfasst als Flame Graphs, die genau zeigen, wo CPU Time während des Incidents verbrachte wurde. Das verwandelt Performance Debugging von einer Reactive Investigation in eine Retrospective Analysis.

eBPF für Security: Der Kernel als First Responder

Observability ist nur die halbe Story. eBPF ist gleichermaßen transformativ für Runtime Security und die Convergence von Observability und Security in einen Single Kernel-Level Agent ist eine der wichtigsten Architektur Shifts in moderner Infrastruktur.

Runtime Threat Detection

Traditionelles Security Monitoring beruht auf Log Analysis — Untersuchung von Application Logs, Audit Logs und System Logs nach Indicators of Compromise. Dieser Ansatz hat grundsätzliche Limitationen: Angreifer können Logs modifizieren oder supprimieren, Anwendungen können Security-Relevant Events nicht loggen und Log Shipping führt zu Latency zwischen einem Event und seiner Detection.

eBPF-basiertes Security Monitoring operiert auf einer anderen Ebene. Durch Hooking in System Calls und Kernel Events, observiert es Activities, die kein Log supprimieren kann:

Process Execution: Jeder Process auf einem System gespawnt, einschließlich jener, die durch Container Breakout Exploits gestartet werden
File Access: Jede File geöffnet, gelesen, geschrieben oder gelöscht, einschließlich Access zu sensitiven Paths wie /etc/shadow oder Cryptographic Keys
Network Connections: Jede Outbound Connection, einschließlich jener, die Application-Level Network Policies umgehen
Privilege Escalation: System Calls, die Process Capabilities, User IDs oder Security Contexts modifizieren
Kernel Module Loading: Attempts, Kernel Modules zu laden, was Rootkit Installation anzeigen kann

Policy Enforcement

Detection ist wertvoll, aber Prevention ist besser. eBPF LSM (Linux Security Module) Hooks ermöglichen Security Policies, direkt im Kernel durchgesetzt zu werden, wobei Unauthorized Actions blockiert werden, bevor sie wirksam werden.

Tetragon, entwickelt vom Cilium Team, ist das führende Tool in diesem Space. Es bietet:

Process Execution Policies: Define, welche Binaries in einem Container ausgeführt werden dürfen. Wenn eine Shell in einem Container spawned, der nur ein Go Binary laufen sollte, kann Tetragon die Execution blockieren und einen Alert generieren.

Network Policies: Enforce, welche Destinations ein Pod auf Kernel-Ebene sich verbinden kann, wobei potenzielle Container Runtime Vulnerabilities umgeht.

File Access Policies: Restrict, welche Files und Directories ein Process zugreifen kann, dabei Defense-in-Depth über Filesystem Permissions bietet.

Capability Restrictions: Limit, welche Linux Capabilities ein Process exercise kann, sogar wenn der Container Runtime sie grant.

Die Enforcement passiert im Kernel, das bedeutet, dass sie nicht von Application-Level Exploits umgangen werden kann. Ein Angreifer, der Code Execution innerhalb eines Containers gains, kann immer noch nicht Aktionen durchführen, die die eBPF Policy blockiert, weil die Policy durchgesetzt wird, bevor der System Call complete.

Network Security

Cilium, das am weitesten deployete eBPF-basierte Networking Tool, hat redefiniert, wie Network Security in Kubernetes Environments funktioniert. Traditionelle Network Policies operieren auf IP Address und Port Level. Ciliums eBPF-basierte Policies operieren auf Identity und API Level:

Identity-Based Policies: Policies reference Kubernetes Labels und Service Identities anstelle von IP Addresses, wobei die Notwendigkeit, Pod IP Allocations zu tracken, eliminiert
L7 Filtering: HTTP, gRPC und Kafka-Aware Policies, die den Access zu spezifischen API Endpoints, nicht nur Ports restrictiven können
Transparent Encryption: WireGuard-basierte Encryption zwischen Nodes, implementiert im Kernel via eBPF ohne Application Changes zu erfordern
Bandwidth Management: Per-Pod Bandwidth Limits auf Kernel-Ebene durchgesetzt

Das eBPF Tool Ökosystem

Das eBPF Ökosystem hat sich um mehrere Key Projects konsolidiert, jedes addressing eine spezifische Domäne.

Networking und Security

Tool	Purpose	Maintainer
Cilium	Kubernetes Networking, Network Policy, Service Mesh	Isovalent (Cisco)
Tetragon	Runtime Security Enforcement	Isovalent (Cisco)
Falco	Runtime Threat Detection	Sysdig / CNCF
Calico eBPF	Kubernetes Networking mit eBPF Datapath	Tigera

Observability

Tool	Purpose	Maintainer
Coroot	Full-Stack Observability (Metrics, Logs, Traces, Profiling)	Coroot
Hubble	Network Observability für Cilium	Isovalent (Cisco)
Pixie	Kubernetes Observability	New Relic / CNCF
Parca	Continuous Profiling	Polar Signals
Grafana Beyla	Auto-Instrumentation für HTTP und gRPC	Grafana Labs

Tracing und Debugging

Tool	Purpose	Maintainer
bpftrace	High-Level Tracing Language für eBPF	IO Visor
BCC	BPF Compiler Collection Toolkit	IO Visor
bpftool	eBPF Program Management Utility	Linux Kernel

Praktische Adoption: Getting Started

eBPF adoptieren erfordert nicht tiefes Kernel Knowledge. Moderne eBPF Tools abstrahieren weg die Complexity und präsentieren Familiar Interfaces — Dashboards, Alerts und Policy Definitions.

Starting mit Observability

Der Lowest-Risk Entry Point ist Observability. Deploy einen eBPF-basierten Agent wie Coroot oder Grafana Beyla neben Ihren existierenden Monitoring Stack. Der Agent erfordert keine Application Changes — er läuft als privilegierter Container oder DaemonSet und fängt sofort an, Metrics zu sammeln.

Für Kubernetes Environments:

# Deploy Coroot mit Helm
helm repo add coroot https://coroot.github.io/helm-charts
helm repo update coroot
helm install -n coroot --create-namespace coroot-operator coroot/coroot-operator
helm install -n coroot coroot coroot/coroot-ce

# Zugriff auf das Dashboard
kubectl port-forward -n coroot service/coroot-coroot 8080:8080

Innerhalb von Minuten sehen Sie eine Service Map, Latency Metrics für HTTP und Database Connections und Resource Utilization Data — alles erfasst ohne Instrumentation Changes zu Ihren Anwendungen.

Adding Security Enforcement

Sobald Observability vorhanden ist, ist der nächste natürliche Schritt Security Enforcement. Tetragon bietet einen Graduated Path:

Phase 1: Audit Mode. Deploy Tetragon mit Policies im Audit Mode. Es loggt Policy Violations ohne sie zu blockieren, wobei Ihnen Zeit gibt, Ihr Application Behavior zu verstehen und Policies zu verfeinern, bevor Enforcement.

Phase 2: Alert Mode. Connect Tetragon Events zu Ihrem Alerting System. Empfangen Sie Notifications, wenn verdächtige Activity auftritt — Unexpected Processes, Unauthorized Network Connections, Sensitive File Access.

Phase 3: Enforcement Mode. Enable Enforcement auf Policies, die im Audit Mode validiert wurden. Beginnen Sie mit den kritischsten Restrictions — Container Breakout Prevention, zum Beispiel — und erweitern Sie gradual Coverage.

Kernel Requirements

eBPF Capabilities hängen von der Linux Kernel Version ab. Für modernes eBPF Observability und Security Tools brauchen Sie:

Feature	Minimum Kernel	Recommended
Basic eBPF	4.4	5.10+
BTF Support	5.2	5.10+
LSM Hooks	5.7	5.15+
BPF Tokens	6.9	6.9+
Ring Buffer	5.8	5.10+

Die meisten Cloud Provider Managed Kubernetes Services (EKS, GKE, AKS) laufen Kernels, die alle modernes eBPF Features unterstützen. On-Premises Deployments sollten Kernel 5.10 oder später für beste Kompatibilität ansprechen.

Performance Considerations

eBPF Monitoring fügt minimalen Overhead hinzu, aber "minimal" ist nicht "zero":

CPU Overhead: Typischerweise 1-2% für umfassendes Monitoring (Network, Process, File, Profiling)
Memory Usage: 50-200 MB pro Node für den Agent, abhängig von Cardinality
Network Overhead: Metrics und Events werden zu einem Central Server shipped; Bandwidth Usage hängt von Cluster Size und Activity ab
Storage: ClickHouse (verwendet von Coroot) oder Prometheus (verwendet von vielen Tools) erfordert Storage proportional zur Anzahl von Services und Retention Period

Für die meisten Environments sind diese Overheads negligible im Vergleich zu der Visibility, die gewonnen wird. Jedoch sollten High-Frequency Trading Systeme, Real-Time Audio/Video Processing und andere Latency-Critical Workloads eBPF Tools sorgfältig vor Production Deployment benchmarken.

Die Convergence von Security und Observability

Der bedeutendste Trend im eBPF Ökosystem ist die Convergence von Security und Observability in Unified Platforms. Historisch gesehen waren das separate Disziplinen mit separate Tools, separate Teams und separate Budgets. eBPF löscht die technische Boundary.

Wenn ein einzelner Kernel-Level Agent Network Connections, Process Execution, File Access und System Call Patterns erfasst, dienen die gleichen Daten beiden Zwecken:

Observability: „Service As Latency zur Database increase um 200ms nach dem letzten Deployment"
Security: „Ein Unexpected Process spawned in Service As Container und machte eine Outbound Connection zu einer Unknown IP"

Beide Observations kommen von der gleichen eBPF Data Source. Der Unterschied liegt in how die Daten analysiert werden und was Aktionen triggered werden. Diese Convergence reduziert Agent Sprawl (ein Agent anstelle von drei oder vier), eliminiert Data Duplication und ermöglicht Correlation, die zuvor unmöglich war — wie Link eines Security Events zu seinem Performance Impact in Echtzeit.

Tools wie Coroot embody bereits diese Convergence, bietet Observability Dashboards neben SLO Tracking und Anomaly Detection. Cilium und Tetragon zusammen bieten Networking, Observability und Security Enforcement von einer Single Platform. Expect diese Convergence zu accelerate, as das Ökosystem maturiert.

Schlussfolgerung: Die neue Infrastruktur-Layer

eBPF hat sich von einem Linux Kernel Feature zu einer Fundamental Infrastructure Layer entwickelt. Es ist die Technologie hinter dem Networking in den meisten Major Cloud Providers Kubernetes Offerings. Es powert die Observability Platforms, die Traditional APM Agents ersetzt haben. Es setzt die Security Policies durch, die Container zur Runtime schützen.

Für Engineering Teams ist der praktische Takeaway straightforward: Wenn Sie Linux Workloads laufen — besonders in Kubernetes — sollten eBPF-basierte Tools Teil Ihres Infrastructure Stack sein. Die Observability, die Sie ohne Code Changes gain, ist remarkable. Die Security Enforcement, die Sie ohne Application Modifications hinzufügen können, ist transformativ. Und die Convergence beider Capabilities in Unified Platforms vereinfacht Operations auf Wege, die separate Tool Stacks niemals könnten.

Beginnen Sie mit Observability. Fügen Sie Security Enforcement gradually hinzu. Lassen Sie den Kernel die Arbeit machen, die Sie Ihre Anwendungen fragen waren. Die Ergebnisse werden worth it sein.