Wie GitHub eBPF nutzt, um Deployments sicherer zu machen

Robin Böhm

· Published on 08.05.2026

TL;DR: GitHub hat ein eBPF-basiertes System entwickelt, das zirkuläre Abhängigkeiten in Deployment-Skripten automatisch erkennt und blockiert. Nach sechs Monaten im Live-Betrieb ist die mittlere Wiederherstellungszeit (MTTR) bei Incidents messbar gesunken – ein Blaupause für jedes Team, das auf Resilienz in der Deployment-Pipeline setzt.

Am 16. April 2026 veröffentlichten Lawrence Gripper und Aleksey Levenstein vom GitHub-Infrastruktur-Team einen detaillierten Einblick in eine der subtilsten Herausforderungen bei hochverfügbaren Systemen: Was passiert, wenn die eigene Deployment-Pipeline von eben jenen Diensten abhängt, die sie gerade reparieren soll?

Die wichtigsten Punkte

• 📅 Verfügbarkeit: System seit sechs Monaten in Produktion bei GitHub
• 🎯 Zielgruppe: Platform Engineers, Tech Leads, DevOps- und SRE-Teams
• 💡 Kernfeature: Automatische Erkennung und Blockierung von DNS-Requests aus Deployment-Prozessen via eBPF
• 🔧 Tech-Stack: Linux cGroups, cilium/ebpf (Go), CGROUP_SKB, CGROUP_SOCK_ADDR, DNS-Proxy, eBPF Maps

Das Problem: Zirkuläre Abhängigkeiten im Deployment

GitHub hostet seinen eigenen Quellcode auf github.com – und ist damit sein eigener Kunde. Das klingt elegant, birgt aber ein kritisches Risiko: Wenn github.com nicht erreichbar ist, ist auch die Fähigkeit eingeschränkt, das Problem zu beheben.

Das GitHub-Team unterscheidet drei Typen von zirkulären Abhängigkeiten, die in der Praxis auftreten:

1. Direkte Abhängigkeiten: Ein Deployment-Skript versucht, ein Binary direkt von github.com herunterzuladen – genau während GitHub selbst wegen eines MySQL-Ausfalls nicht verfügbar ist.

2. Versteckte Abhängigkeiten: Ein Tool ist bereits auf der Maschine vorhanden, prüft aber beim Start heimlich, ob ein Update verfügbar ist – und hängt sich auf, wenn github.com nicht antwortet.

3. Transiente Abhängigkeiten: Das Deployment-Skript ruft intern einen anderen Service auf (z.B. einen Migrations-Service), der seinerseits etwas von GitHub lädt. Der Fehler propagiert sich zurück.

Für Teams bedeutet das: Viele dieser Abhängigkeiten bleiben unsichtbar, bis ein Incident sie sichtbar macht – oft zum ungünstigsten Zeitpunkt.

Die Lösung: eBPF + cGroups = prozessgranulares Netzwerk-Filtering

eBPF (extended Berkeley Packet Filter) ist eine Linux-Kernel-Technologie, die es erlaubt, kleine Programme sicher im Kernel auszuführen, ohne den Kernel-Code zu modifizieren. Das Team nutzte zwei spezifische eBPF-Programm-Typen:

BPF_PROG_TYPE_CGROUP_SKB – Hooks für ausgehende Netzwerkpakete innerhalb einer cGroup. Damit lässt sich Egress-Traffic für eine dedizierte Prozessgruppe filtern, ohne den Rest der Maschine zu beeinflussen.

BPF_PROG_TYPE_CGROUP_SOCK_ADDR – Hooks auf Socket-Syscalls. Damit werden DNS-Requests (Port 53) aus der cGroup des Deployment-Skripts transparent auf einen lokalen DNS-Proxy umgeleitet.

Der Workflow sieht so aus:

Deployment-Skript startet
      ↓
Prozess wird in dedizierte cGroup gelegt
      ↓
eBPF-Programm (CGROUP_SOCK_ADDR) leitet DNS-Requests → lokalen Proxy
      ↓
DNS-Proxy prüft Domain gegen Blocklist
      ↓
eBPF Map kommuniziert Ergebnis → CGROUP_SKB blockiert oder erlaubt Paket
      ↓
Log-Eintrag mit Domain + PID + Command-Line

Die Implementierung erfolgt in Go mit der cilium/ebpf-Bibliothek, die als reine Go-Library eBPF-Programme kompiliert, lädt und an Kernel-Hooks bindet.

Was Teams und Tech Leads konkret lernen können

1. Prozessgranuläre Sicherheit ohne Produktions-Impact

Das Entscheidende an diesem Ansatz: Deployment-Skripte werden in eine eigene cGroup gelegt. Nur dieser Prozess unterliegt den Netzwerk-Beschränkungen – der restliche Produktions-Traffic der Maschine läuft ungestört weiter. Das löst das klassische Dilemma: “Wir können github.com nicht einfach blockieren, weil die Hosts ja Produktions-Traffic bedienen.”

2. DNS als Sicherheitsebene – mit Name-basierter Blocklist

Da CGROUP_SKB nur auf IP-Adressen arbeitet, wäre eine IP-Blockliste bei Githubs dynamischer Infrastruktur kaum wartbar. Der DNS-Proxy-Ansatz löst das elegant: Domains werden per Name blockiert, die aufgelöste IP dann via eBPF Map an den Egress-Filter übergeben.

3. Automatisches Prozess-Tracing für schnelleres Debugging

Mit bpf_get_current_pid_tgid() kann das System die PID des blockierten Prozesses erfassen und via /proc/{PID}/cmdline den exakten Befehl auslesen. Teams erhalten sofort umsetzbare Fehlermeldungen statt rätselhafter Timeouts:

WARN DNS BLOCKED domain=github.com. pid=266767 cmd="curl github.com" firewallMethod=blocklist

Das ist ein erheblicher Unterschied zur bisherigen Situation, in der Teams erst im Nachgang durch Log-Analysen herausfinden mussten, welcher Schritt in welchem Skript die Abhängigkeit verursacht hat.

4. MTTR-Verbesserung als messbares Ergebnis

Nach sechs Monaten Live-Betrieb bei GitHub: Das System erkennt neue Abhängigkeiten proaktiv, bevor sie im Incident-Kontext auffallen. Teams werden automatisch benachrichtigt, wenn ihre Skripte problematische Verbindungen aufbauen würden. Die mittlere Wiederherstellungszeit bei Incidents, die zuvor durch solche zirkulären Abhängigkeiten verlängert wurden, ist messbar gesunken.

Einordnung: eBPF im Platform Engineering 2026

eBPF hat sich in den letzten Jahren zur Schlüsseltechnologie für Platform Engineers entwickelt. Tools wie Cilium (Kubernetes-Netzwerking und Security Policies), bpftrace (ad-hoc Kernel-Tracing) und Datadog Workload Protection (Runtime Security) bauen alle auf eBPF auf.

Für Teams, die noch keine eBPF-Erfahrung haben, empfiehlt das GitHub-Team als Einstieg:

1. Beobachten vor Kontrollieren: Mit bpftrace oder ptcpdump zunächst verstehen, was tatsächlich passiert – ohne Enforcement
2. cilium/ebpf-Bibliothek: Die Go-Library reduziert die eBPF-Lernkurve erheblich – kein direktes C/BCC nötig
3. Kernel-Version prüfen: eBPF-Features sind stark kernel-versionsabhängig – Testmatrix frühzeitig definieren

Praktische nächste Schritte

1. Proof of Concept testen: GitHub hat den frühen PoC unter github.com/lawrencegripper/ebpf-cgroup-firewall veröffentlicht
2. Eigene Deployment-Abhängigkeiten kartieren: Welche externen Domains rufen eure Deployment-Skripte auf? Ein einfacher DNS-Trace während einer Staging-Deployment-Runde kann überraschende Ergebnisse liefern
3. eBPF-Grundlagen aufbauen: Die Beispiele in cilium/ebpf und docs.ebpf.io sind gut dokumentierte Einstiege
4. Kubernetes-Kontext: Teams, die Kubernetes betreiben, können Cilium als eBPF-natives CNI evaluieren – viele eBPF-Konzepte aus diesem Artikel sind direkt übertragbar