Cilium: eBPF-basiertes Networking für Zero-Trust und Compliance

TL;DR

• Cilium nutzt eBPF, um Netzwerkfunktionen direkt im Linux-Kernel auszuführen – das ermöglicht hochperformantes, identitätsbasiertes Networking für moderne Kubernetes-Plattformen.
• Für Zero-Trust-Architekturen stellt Cilium zentrale Bausteine bereit: feingranulare Network Policies (Mikrosegmentierung), Ende-zu-Ende-Verschlüsselung via WireGuard, tiefgehende Observability mit Hubble und Intrusion-Detection-Funktionen.
• eBPF kombiniert Performance, Flexibilität und Sicherheit: es erweitert den Kernel kontrolliert, ohne ihn patchen zu müssen, und schafft damit eine solide technische Grundlage für regulatorisch geforderte Transparenz und Steuerbarkeit von Netzwerkverkehr.
• Namespace-Isolation lässt sich mit Cilium so umsetzen, dass Mandanten klar voneinander getrennt sind, nur explizit erlaubte Verbindungen möglich sind und alle Flows revisionssicher nachvollzogen werden können – ein direkter Hebel für Auditfähigkeit und Compliance.
• ayedo setzt Cilium als Standard-Netzwerkkomponente in der eigenen Kubernetes-Distribution ein, integriert es in Logging, Monitoring und Governance-Prozesse und unterstützt Organisationen dabei, Zero-Trust- und Compliance-Anforderungen pragmatisch umzusetzen.

---

Warum Netzwerk-Security zur Compliance-Grundlage wird

Netzwerkkommunikation ist längst nicht mehr „nur“ ein Infrastrukturthema. Sie ist zu einem zentralen Baustein für Informationssicherheit und damit für regulatorische Konformität geworden.

Mit der NIS2-Richtlinie, die bis zum 17.10.2024 in nationales Recht umgesetzt sein muss, werden europaweit strengere Anforderungen an die Sicherheit kritischer und wichtiger Einrichtungen verbindlich. DORA tritt am 17.01.2025 in Kraft und adressiert explizit die digitale Resilienz im Finanzsektor. Beide Regulierungsstränge verlangen im Kern dasselbe: nachvollziehbare, steuerbare und überprüfbare Kontrolle über Datenflüsse.

Gleichzeitig arbeiten immer mehr Teams auf Basis von Kubernetes, Microservices und hochdynamischen Plattformen. Dort ändern sich IPs, Pods und Workloads ständig – klassische, IP-basierte Netzwerksicherheit skaliert unter diesen Bedingungen kaum noch. Was in statischen Rechenzentren funktionierte, wird in einem Cloud-Native-Umfeld schnell zum Governance-Risiko.

Zero-Trust-Ansätze, bei denen jede Verbindung explizit autorisiert und überwacht wird, sind damit nicht nur ein Sicherheitsparadigma, sondern ein handfestes Compliance-Werkzeug. Genau hier setzt Cilium mit eBPF an: Netzwerk und Security werden dorthin verlagert, wo sie in modernen Infrastrukturen hingehören – ins Herz des Betriebssystems und nah an die Workloads.

---

Cilium und eBPF im Überblick: Networking im Kernel

Cilium ist eine Cloud-Native Networking- und Security-Plattform, die speziell für containerisierte Umgebungen wie Kubernetes entwickelt wurde. Kernidee: Netzwerk-Logik nicht mehr in iptables-Regelwerken, Sidecar-Proxies oder externen Appliances abzubilden, sondern direkt im Linux-Kernel – mithilfe von eBPF.

Was ist eBPF – in verständlichen Begriffen?

eBPF (extended Berkeley Packet Filter) ist eine Technologie, mit der kleine, spezialisierte Programme sicher in den Kernel geladen und an bestimmte „Ereignisse“ gekoppelt werden können, zum Beispiel:

• Netzwerkpakete (eingehend/ausgehend)
• Systemaufrufe (syscalls)
• Tracepoints im Scheduler oder Dateisystem

Diese Programme laufen in einer Art „Sandbox“ im Kernel: Ein Verifier prüft vor der Ausführung, dass sie keine unsafe Operationen ausführen, sich nicht endlos schleifen und nur erlaubte Ressourcen nutzen. Im Ergebnis lässt sich das Betriebssystem sehr fein und gezielt erweitern, ohne neue Kernel-Module schreiben oder den Kernel neu kompilieren zu müssen.

Für Networking bedeutet das: Wir können Routing, Load Balancing, Policy-Enforcement und Observability direkt dort implementieren, wo die Pakete verarbeitet werden – ohne Umwege und overhead-intensiven Technologiestapel.

Cilium als eBPF-basiertes CNI

In einer Kubernetes-Umgebung übernimmt Cilium unter anderem folgende Aufgaben:

• Container Networking Interface (CNI) – Pod-zu-Pod- und Pod-zu-Service-Kommunikation
• Identitätsbasierte Network Policies – Steuerung von Verbindungen nicht nur nach IP/Port, sondern nach Service-/Pod-Identity
• In-Kernel Load Balancing – ohne kube-proxy, mit deutlich weniger Overhead
• Service Mesh-Funktionalität – service-to-service Security ohne obligatorische Sidecar-Proxies
• Observability & Security – Auswertung von Netzwerkflüssen, Protokollen und Metadaten in Echtzeit

Diese Funktionen sind für Compliance deshalb interessant, weil sie direkt an zentralen Kontrollpäunkten greifen: Wer darf mit wem reden? Welche Protokolle werden genutzt? Werden Policies durchgesetzt? Wie weise ich einem Auditor nach, dass das System wie spezifiziert arbeitet?

---

Compliance-relevante Features von Cilium

Mikrosegmentierung mit Network Policies

Ein Kernprinzip von Zero Trust ist Mikrosegmentierung: Statt eines großen, „flachen“ Netzwerks werden Workloads in logisch getrennte Segmente unterteilt, und zwischen diesen Segmenten gelten strikte Regeln.

Cilium setzt hier auf identitätsbasierte Network Policies:

• Policies werden auf Basis von Labels, Services und Kubernetes-Identitäten definiert, nicht nur IP-Adressen.
• Sie können mehrere Ebenen abdecken – vom klassischen L3/L4 (IP/Port) bis hin zum L7-Layer (HTTP-Methoden, Pfade, DNS-Namen).
• Default-deny-Strategien lassen sich konsequent umsetzen: Alles ist verboten, was nicht explizit erlaubt wurde.

Für Compliance bedeutet das:

• Klare Trennung von Mandanten und Umgebungen (z. B. Produktion vs. Test).
• Begrenzung von lateralen Bewegungen im Falle eines Angriffs – ein regulatorisch geforderter Baustein zur Schadensbegrenzung.
• Dokumentierbare, versionierte Regeln: Network Policies sind deklarativ und können in Git verwaltet werden (Policy as Code).

So wird das Netzwerk zur kodifizierten Sicherheitsarchitektur, die überprüfbar, reproduzierbar und auditierbar ist.

Verschlüsselung mit WireGuard

Regelwerke wie NIS2, DORA oder ISO 27001 verlangen in der Regel die Verschlüsselung sensibler Daten „in Transit“. Cilium unterstützt dies nativ über WireGuard:

• Pod-zu-Pod- oder Node-zu-Node-Verbindungen können transparent verschlüsselt werden.
• Die Verschlüsselung läuft im Kernel und ist dadurch performanter als viele „User-Space“-Lösungen.
• Schlüsselmanagement und Tunnelaufbau werden automatisiert gemanagt, ohne dass Teams eigene IPsec-Konfigurationen pflegen müssen.

Damit lassen sich auch interne Netzwerksegmente so absichern, dass ein Abhören des Datenverkehrs deutlich erschwert wird – ein wichtiger Punkt, wenn Rechenzentren oder Cloud-Umgebungen von externen Providern betrieben werden.

Observability mit Hubble

Transparenz ist ein zentraler Pfeiler von Compliance: Es geht nicht nur darum, Security-Maßnahmen zu haben, sondern sie auch nachweisen zu können. Hubble, das Observability-Subsystem von Cilium, adressiert genau das:

• Es zeichnet Netzwerkflüsse in strukturierter Form auf: Wer spricht wann mit wem, über welches Protokoll, mit welchem Ergebnis (erlaubt/blockiert).
• Die Daten können in Metrik- und Logsysteme integriert und dort visualisiert werden, zum Beispiel mit Grafana.
• Verdächtige Muster (ungewöhnliche Verbindungsversuche, viele Fehlversuche, Policy-Verletzungen) werden sichtbar.

Diese Informationen können Sie nutzen, um:

• technische und organisatorische Maßnahmen gegenüber Auditoren zu belegen
• Security-Incidents forensisch zu analysieren
• kontinuierliche Verbesserungsprozesse zu etablieren (z. B. Tuning von Policies auf Basis realer Traffic-Profile)

Intrusion Detection & Anomalieerkennung

Auf Basis von eBPF hat Cilium Zugriff auf sehr detaillierte Kontextinformationen zu Netzwerkereignissen. Dies ermöglicht ein modernes Intrusion-Detection-Verhalten:

• Erkennen von ungewöhnlichen Mustern, etwa massenhafte Port-Scans zwischen Pods oder exfiltrationsartige Datenströme
• Korrelation mit Identitäten und Namespaces, statt nur mit IPs
• Export von Events an zentrale SIEM- oder Security-Plattformen

Für Compliance-relevante Standards, die ein Security Incident & Event Management verlangen, ist das ein entscheidender Vorteil: Ereignisse werden frühzeitig erkannt, mit Kontext angereichert und können in standardisierte Incident-Prozesse überführt werden.

---

Technische Eigenschaften von eBPF: Performance, Flexibilität, Sicherheit

Performance: Netzwerkfunktionen ohne Umwege

Klassische Paketverarbeitung in Container-Umgebungen führt häufig durch mehrere Abstraktionsschichten:

• virtuelle Interfaces
• iptables-Regelwerke
• User-Space-Proxies (z. B. kube-proxy, Sidecar-Proxies)

Jede Schicht kostet Latenz und CPU-Zeit.

Mit eBPF können zentrale Funktionen direkt im Kernel ausgeführt werden:

• Routing-Entscheidungen werden dort getroffen, wo die Pakete ankommen.
• Load Balancing erfolgt ohne Umweg über Userspace-Prozesse.
• Policy-Enforcement erfordert keine langen iptables-Ketten.

In der Praxis resultiert das in deutlich geringerer Latenz und besserer Skalierbarkeit – ein Aspekt, der gerade bei hoher Service-Dichte und strengen SLAs relevant ist.

Flexibilität: Erweiterbarkeit ohne Kernel-Patches

Gerade im europäischen Kontext greifen Unternehmen auf eine Vielzahl von Linux-Distributionen und Cloud-Umgebungen zurück. Klassische Kernel-Erweiterungen sind hier schwer zu standardisieren.

eBPF bietet:

• Portabilität: eBPF-Programme laufen auf verschiedenen Kernel-Versionen, ohne dass der Kernel selbst angepasst werden muss.
• Schnelle Innovation: Neue Features können als Userspace-Komponenten plus eBPF-Programme ausgeliefert werden – Updates sind damit deutlich risikoärmer.
• Feinheit: Statt monolithischer Firewall-Regeln lassen sich punktgenaue Programme erstellen, die exakt das tun, was benötigt wird.

Das erleichtert den Aufbau standardisierter Plattformen über verschiedene Standorte und Länder hinweg, ohne bei jedem Sicherheitsupdate tief in den Kernel eingreifen zu müssen.

Sicherheit: Verifizierte Programme im Kernel

Ein berechtigter Reflex lautet: „Programmcode im Kernel? Ist das nicht gefährlich?“ eBPF adressiert diese Sorge durch:

• Verifier: Ein statischer Analysator prüft jedes Programm, bevor es in den Kernel geladen wird. Unsichere Programme werden abgelehnt.
• Begrenzte Fähigkeiten: eBPF-Programme haben keinen uneingeschränkten Zugriff auf Kernel-Funktionen; sie folgen einem klar definierten API-Satz.
• Ressourcenlimits: Laufzeit, Stackgröße und Speicherzugriffe sind begrenzt und kontrolliert.

Damit entsteht eine kontrollierte Erweiterbarkeit, die sich grundsätzlich besser auditieren lässt als individuelle Kernel-Patches oder proprietäre Firewall-Appliances mit intransparenten Regelwerken.

---

Praktisches Beispiel: Namespace-Isolation als Zero-Trust-Baustein

Ein typischer Anwendungsfall in größeren Organisationen ist die saubere Trennung verschiedener Mandanten oder Domänen innerhalb eines Clusters: Fachbereiche, Tochtergesellschaften, Entwicklungs- und Produktionsumgebungen. Auf Kubernetes-Ebene erfolgt diese Trennung häufig über Namespaces. Cilium kann daraus einen klaren, Zero-Trust-konformen Sicherheitsperimeter machen.

1. Mandantenmodell und Namespaces definieren

Zunächst wird ein klares Mandantenmodell erstellt:

• Jeder Mandant oder jede Umgebung erhält eigene Namespaces (z. B. prod-banking, prod-insurance, test-shared).
• Technische Services, die von mehreren Mandanten genutzt werden (z. B. Logging, Identity), werden in dedizierten „Shared-Services-Namespaces“ betrieben.

Dieser Schritt ist organisatorisch: Es geht darum, Verantwortlichkeiten, Datenklassifikationen und Abhängigkeiten sauber zu erfassen.

2. Identitäten über Labels und Services festlegen

Auf dieser Basis werden die Workloads mit konsistenten Labels versehen, etwa:

• tenant=banking
• env=prod
• component=api / component=db

Diese Metadaten sind der Rohstoff für Cilium Network Policies: Sie ermöglichen, dass Regeln sich an fachlich nachvollziehbaren Eigenschaften orientieren, nicht an flüchtigen IP-Adressen.

3. Default-deny zwischen Namespaces etablieren

Mit Cilium wird nun eine unternehmensweite Grundregel eingeführt:

• Zwischen Mandanten-Namespaces gibt es standardmäßig keine Verbindungen.
• Innerhalb eines Namespaces ist nur das erlaubt, was für den jeweiligen Service sinnvoll ist (z. B. API → DB, aber kein direkter Zugriff zwischen zwei unabhängigen Fachanwendungen).

Operativ bedeutet das:

• Es wird eine Policy definiert, die jede Cross-Namespace-Kommunikation unterbindet, sofern keine explizite Ausnahme besteht.
• Hubble wird genutzt, um zunächst im „Audit“-Modus zu beobachten, welche Verbindungen aktuell stattfinden, bevor Policies strikt durchgesetzt werden.

4. Explizite Freigaben für Shared Services

Viele Architekturen benötigen zentrale Dienste: Logging, Monitoring, Identity, zentrale Datenpools. Diese werden nun bewusst und sauber freigeschaltet:

• Regeln erlauben z. B. env=prod-Workloads, den Zugriff auf den zentralen Auth-Service im shared-auth-Namespace.
• Alle anderen Cross-Namespace-Verbindungen bleiben blockiert.

Das Ergebnis: Ein Zero-Trust-Netzwerk, in dem jede Ausnahme nachvollziehbar dokumentiert ist – ein wichtiges Argument in Audits und Risikoanalysen.

5. Monitoring, Audit und kontinuierliche Anpassung

Abschließend wird Hubble dauerhaft genutzt, um:

• neue Verbindungsversuche zu erkennen, die durch Policies blockiert werden
• ungewöhnliche Traffic-Muster zu identifizieren
• Reports und Dashboards für interne und externe Audits aufzubauen (z. B. in Kombination mit Grafana)

So bleibt das Regelwerk nicht statisch, sondern wird kontinuierlich verbessert – im Sinne eines dauerhaften Compliance- und Sicherheitsprozesses.

---

Häufige Fragen

Ist eBPF im Produktionsbetrieb „reif“ genug für kritische Workloads?

Ja, eBPF ist inzwischen in vielen großen Produktionsumgebungen etabliert – von hyperskalierenden Cloud-Anbietern bis hin zu regulierten Branchen. Der Linux-Kernel unterstützt eBPF seit Jahren, und seine Sicherheitsmechanismen (Verifier, Sandbox, eingeschränkte APIs) wurden über unzählige reale Einsätze weitergehärtet.

Für Betreiber bedeutet das:

• Sie setzen auf einen Open-Source-Stack mit breiter Community- und Enterprise-Adoption.
• Risiken sind transparent dokumentiert und werden schnell adressiert.
• Die Integration mit Standard-Linux-Distributionen ist robust und gut getestet.

Wichtiger als die reine Technologiefrage ist eine saubere Betriebsverantwortung: Wer beobachtet das System, wer pflegt Policies, wie werden Updates ausgerollt? Genau hier setzt eine professionelle Plattform- und Betriebsstrategie an.

Wie unterstützt Cilium bei der Erfüllung von NIS2-, DORA- oder ISO-Anforderungen?

Cilium adressiert mehrere typische Kontrollbereiche, die in vielen Regulierungen vorkommen:

• Zugangskontrolle und Segmentierung: Mikrosegmentierung und identitätsbasierte Network Policies begrenzen den Zugriff auf Dienste auf das notwendige Maß.
• Schutz der Vertraulichkeit: WireGuard-Verschlüsselung schützt Daten in Transit, auch innerhalb interner Cluster-Netzwerke.
• Monitoring und Logging: Hubble liefert detaillierte, auswertbare Netzwerkprotokolle, die für Incident-Management und Audits genutzt werden können.
• Technische Härtung: eBPF-basierte Sicherheitsfunktionen ergänzen klassische Controls wie TLS, IAM und Host-Hardening.

Cilium ist damit kein alleiniger „Compliance-Schalter“, aber ein zentrales technisches Bauteil einer belastbaren Compliance-Architektur, insbesondere für containerisierte und Cloud-Native-Workloads.

Wie integriert ayedo Cilium in seine Kubernetes-Plattform?

In der ayedo Kubernetes Distribution ist Cilium die standardisierte Networking- und Security-Komponente. Konkret bedeutet das:

• Cilium wird als CNI sowie für Load Balancing und Network Policies vorkonfiguriert ausgeliefert.
• Hubble ist in das zentrale Monitoring- und Logging-Setup integriert, inklusive Dashboards und Alerting.
• Updates, Sicherheitsfixes und Konfigurationsänderungen erfolgen kontrolliert und getestet im Rahmen des Plattformbetriebs.
• Gemeinsam mit unseren Kundenteams erarbeiten wir Richtlinien (z. B. Namespace- und Mandantenmodelle), die sowohl technische Anforderungen als auch regulatorische Vorgaben berücksichtigen.

So entsteht eine Plattform, bei der Networking, Security und Compliance von Anfang an zusammengedacht sind – statt später mühsam nachgerüstet zu werden.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Cilium und eBPF liefern eine überzeugende Antwort auf viele Herausforderungen moderner Plattformen: Zero-Trust-Networking, feingranulare Kontrolle, tiefgehende Observability und eine stabile Basis für regulatorische Anforderungen. Entscheidend ist jedoch nicht nur die Technologie, sondern ihre Einbettung in eine tragfähige Betriebs- und Governance-Struktur.

In der ayedo Kubernetes Distribution ist Cilium integraler Bestandteil der Plattform – kein optionales Add-on. Dadurch können wir:

• Namespaces, Policies und Verschlüsselung konsistent über alle Cluster hinweg etablieren,
• Hubble-Daten zentral auswerten und in bestehende Monitoring- und Security-Prozesse integrieren,
• gemeinsam mit Ihren Security- und Compliance-Verantwortlichen ein Regelwerk entwickeln, das technische Möglichkeiten und regulatorische Anforderungen in Einklang bringt.

Für Sie als Verantwortliche oder Verantwortlicher bedeutet das: Sie müssen nicht im Detail verstehen, wie eBPF an den Kernel-Hooks ansetzt. Aber Sie können sich darauf verlassen, dass Netzwerkarchitektur, Zero-Trust-Prinzipien und Compliance-Anforderungen auf einer modernen, nachvollziehbaren und auditierbaren Basis umgesetzt sind.

Wenn Sie prüfen möchten, welche konkreten Funktionen von Cilium in Ihrer Umgebung den größten Hebel für Sicherheit und Compliance bieten – etwa Mikrosegmentierung, Verschlüsselung oder Intrusion Detection – lohnt sich ein Blick in die offizielle Cilium-Dokumentation und die darauf aufbauenden Plattform-Bausteine.

Cilium Dokumentation