eBPF Security Monitoring — Du nutzt Kernel-Module für Security Monitoring. Kernel-Panic, dein Cluster ist down. GKE blockiert Kernel-Module. Du bist blind.
Du nutzt Kernel-Module für Security Monitoring. Kernel-Panic, dein Cluster ist down. GKE blockiert Kernel-Module. Du bist blind. Hier ist, wie du das verhinderst.
Was ist eBPF? Einfach erklärt.
eBPF (extended Berkeley Packet Filter) ist eine Linux-Kernel-Technologie, die sandboxed-Programme im Kernel ohne Kernel-Module ausführt. Vorteile: Sicherheit (Verifier verhindert Kernel-Panic), Portabilität (funktioniert über Kernel-Versionen), Managed-Kubernetes-Kompatibilität (GKE, EKS, AKS). Gutes eBPF-Monitoring: Cilium Tetragon (Enforcement), Falco eBPF (Detection), L7-Network-Policies, Syscall-Audit-Trail.
↓ Springe direkt zur technischen Tiefe4 eBPF Security Tools
Kernel-level security enforcement with eBPF. Tetragon executes security policies in-kernel — blocking malicious syscalls before they complete, not just alerting after.
# Install Tetragon via Helm
helm repo add cilium https://helm.cilium.io
helm install tetragon cilium/tetragon -n kube-system
# TracingPolicy: alert on shell execution inside containers
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: block-shell-in-containers
spec:
kprobes:
- call: "sys_execve"
syscall: true
args:
- index: 0
type: "string"
selectors:
- matchArgs:
- index: 0
operator: "Postfix"
values: ["/sh", "/bash", "/ash", "/dash"]
matchNamespaces:
- namespace: Pid
operator: NotIn
values: ["host_ns"] # Container processes only
matchActions:
- action: Sigkill # KILL the process — not just alert
# or action: Override with argError: -1 for syscall overrideFalco with eBPF driver instead of kernel module — same detection capabilities without loading a kernel module (safer, works in managed K8s where modules are blocked).
# Deploy Falco with eBPF driver (no kernel module required)
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
--set driver.kind=ebpf \
--set falcosidekick.enabled=true \
--set falcosidekick.config.webhook.address=http://openclaw-webhook:9000
# Key Falco rules for container security:
- rule: Unexpected shell in container
condition: >
spawned_process and container and
shell_procs and not proc.pname in (allowed_parent_processes)
output: Shell spawned in container (proc=%proc.name parent=%proc.pname
container=%container.name image=%container.image.repository)
priority: WARNING
- rule: Write below /etc in container
condition: >
open_write and container and
fd.name startswith /etc
output: File below /etc written in container (file=%fd.name
container=%container.name)
priority: ERROR
- rule: Outbound connection to unexpected IP
condition: >
outbound and container and
not fd.sip in (allowed_outbound_ips)
output: Unexpected outbound connection (sip=%fd.sip dport=%fd.sport
container=%container.name)
priority: WARNINGCilium uses eBPF to enforce network policies at Layer 7 (HTTP/gRPC/DNS) — blocking specific API calls or DNS queries, not just TCP connections.
# Cilium L7 policy: allow only specific HTTP paths
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: moltbot-agent-l7-policy
namespace: moltbot-agents
spec:
endpointSelector:
matchLabels:
app: moltbot-agent
egress:
- toEndpoints:
- matchLabels:
app: llm-gateway
toPorts:
- ports:
- port: "8080"
protocol: TCP
rules:
http:
- method: "POST"
path: "/v1/chat/completions" # Only allow LLM API calls
# BLOCKED: GET /, POST /admin, all other paths
- toFQDNs:
- matchName: "api.openai.com"
toPorts:
- ports:
- port: "443"
protocol: TCP
rules:
http:
- method: "POST"
path: "/v1/chat/completions"
# Block metadata API (cloud credential theft prevention)
egressDeny:
- toCIDRSet:
- cidr: "169.254.169.254/32"Record every syscall from every container process with full context — process, arguments, return value. Immutable audit trail for incident response and compliance.
# Tetragon: comprehensive syscall audit with JSON export
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: audit-sensitive-syscalls
spec:
kprobes:
- call: "sys_ptrace" # Process tracing (escape vector)
syscall: true
return: true
- call: "sys_mount" # Filesystem mount (escape vector)
syscall: true
return: true
- call: "sys_clone" # Namespace creation (escape vector)
syscall: true
args:
- index: 0
type: "uint64" # flags
return: true
- call: "sys_setuid" # Privilege escalation
syscall: true
return: true
# Export audit events to SIEM:
# Tetragon exports JSON to stdout → ship via Fluent Bit to SIEM
# Each event includes: timestamp, pod, namespace, process, args, return_val
# Cryptographic integrity: sign log stream with Falco/Tetragon + HMACReal-World Scars: Production Incidents
Kernel-Modul für Falco geladen, Kernel-Panic, Cluster-Down. Fix: Falco mit eBPF-Driver nutzen (kein Kernel-Modul).
GKE blockiert Kernel-Module, Falco nicht deploybar. Fix: Nutze eBPF-Driver (funktioniert ohne Kernel-Module).
Sofortmaßnahmen: Was heute tun?
Falco mit eBPF-Driver deployen
--set driver.kind=ebpf nutzen.
Cilium Tetragon installieren
TracingPolicy für Shell-Block erstellen.
L7-Network-Policies aktivieren
Cilium L7-Policies für HTTP/gRPC.
Syscall-Audit-Trail einrichten
Tetragon Audit-Policy für sensitive Syscalls.
Interaktive eBPF Security Checkliste
eBPF Security Score Calculator
Industrie-Durchschnitt: 20/100
Häufige Fragen
Was ist eBPF und warum besser als Kernel-Module?
eBPF (extended Berkeley Packet Filter) ist eine Linux-Kernel-Technologie, die sandboxed-Programme im Kernel ohne Kernel-Module ausführt. Vorteile: Sicherheit: eBPF-Programme werden vom Kernel-Verifier vor Ausführung geprüft — können den Kernel nicht crashen. Kernel-Module können Kernel-Panics auslösen. Portabilität: eBPF-Programme funktionieren über Kernel-Versionen ohne Neukompilierung. Managed Kubernetes: GKE, EKS, AKS blockieren Kernel-Module. eBPF funktioniert ohne spezielle Berechtigungen. Performance: eBPF führt im Kernel aus — keine Kontextwechsel.
Cilium Tetragon vs Falco — Unterschied?
Beide nutzen eBPF mit unterschiedlichen Ansätzen: Falco: observe-and-alert. Detektiert Policy-Verletzungen, sendet Alerts. Kann nicht blockieren — nur melden. Cilium Tetragon: enforce-and-kill. Führt Security-Policies im Kernel aus, kann/killt bösartige Prozesse vor Syscall-Completion. Best Practice: beide nutzen — Falco für Detection-Coverage, Tetragon für Enforcement auf kritischen Workloads.
Funktioniert eBPF mit AI-Agent-Containern?
Ja, besonders wertvoll: AI-Agent-Containern (Moltbot) haben oft breiten Netzwerk-Zugriff und Tool-Capabilities — eBPF-Monitoring gibt Sichtbarkeit in genaue Syscalls und Netzwerk-Verbindungen. Use Cases: 1) Prompt-Injection-Detection, die zu Shell-Execution führt. 2) Outbound-Connection-Monitoring. 3) L7-Network-Policy-Enforcement. 4) Audit-Tool-Calls auf Syscall-Level.
Performance-Overhead von eBPF-Monitoring?
Production-gemessener Overhead: Falco eBPF: 1-3% CPU. Spikes bis 5-10% bei hohen Syscall-Perioden. Cilium Network Policies: ~1% für L3/L4. L7-Inspektion ~3-5% für HTTP-Workloads. Cilium Tetragon: 2-5% mit umfassender TracingPolicy. Optimierung: TracingPolicy auf spezifische Namespaces scopen. Falco-Regeln für High-Frequency-Events droppen.