Will man den Netzwerkverkehr überwachen und auf verdächtige Abweichungen überprüfen, so kann man dies bei traditionellen IT Systemen mit handelsüblichen Tools tun. Bei Kubernetes stößt man aber schnell an Grenzen, da die IP-Adressen von Pods, genau wie andere Laufzeitdaten, vergänglich sind und nicht permanent abgelegt werden. Rückblickende Aussagen sind damit unmöglich und eine forensische Aufarbeitung wird erschwert. Kubernetes strukturiert seine Ressourcen intern mit Hilfe von Labels, einer Abstraktion mit Key-Value-Paaren und selbst definierter Logik. So funktioniert die Adressierung eines Pods persistent, auch ohne die momentane IP Adresse kennen zu müssen. Vergleicht man diese beiden Aspekte - vergängliche IP-Adressen sowie persistente Labels - so liegt es nahe, auf IP-Adressen zu verzichten und stattdessen den Netzwerkverkehr anhand von Labels zu verwalten und zu überwachen.

Wie kann aber ein Container selbst wissen, was um ihn herum geschieht, und wie interagiert er netzwerkseitig mit anderen Containern? Container teilen sich den Kernel mit dem Host, d.h. alle Container auf einem System haben Zugriff auf denselben Kernel. Mit eBPF ist der Kernel aus dem User-Space heraus programmierbar geworden, ähnlich wie JavaScript den Browser programmierbar macht. Cilium nutzt dies im Netzwerkbereich, um Datenverkehr im Kubernetes Cluster sichtbar zu machen, zu konfigurieren und abzusichern. Es ist ein an das Cloud-Native Zeitalter angepasster tcpdump mit einer Vielzahl an Funktionen und Möglichkeiten, die sich aus der eBPF Technologie ergeben. Neben der Sichtbarmachung des gesamten Netzwerkverkehrs in einem Cluster und der Zugriffe nach außen, können diese mittels WebUI in Network Policies umgewandelt werden, so dass Zugriffe auf FQDNs einfach von “erlaubt” auf “verboten” gestellt werden können. Nur das Frontend mit dem passenden Label soll auf das Backend zugreifen dürfen? Auch das ist unproblematisch einstellbar, ganz ohne Sidecar Container.