Container-Anwendungen isolieren mit Aporeto Trireme

Schauen wir uns eine einfache Web-applikation an, besteht diese aus mehreren Schichten. So existiert im klassischen Modell eine Präsentationsschicht, die für die korrekte Darstellung der Anwendung innerhalb eines Webbrowsers zuständig ist, danach folgt die Applikationsschicht, in der die eigentliche Applikationslogik verarbeitet wird, und schließlich gibt es eine Datenbankschicht. Um dieses klassische Konzept noch weiter zu vereinfachen, lassen sich die einzelnen Schichten oftmals auch in die beiden Kategorien "Backend" und "Frontend" unterteilen.

Typischerweise sind diese Bereiche voneinander isoliert, sodass ein direkter Zugriff von einer Anwendung im Frontend auf eine Anwendung im Backend nur über ganz bestimmte, zuvor definierte Pfade möglich ist. So ist es typischerweise nicht möglich, dass der Webserver im Frontend eine direkte Abfrage in der Datenbank im Backend durchführt. Diese Aufgabe ist dem Anwendungsserver in der Applikationsschicht vorbehalten. Da der Frontend-Bereich weit weniger gut isoliert ist als der Backend-Bereich, könnte eine Schwachstelle in einer dort laufenden Applikation ansonsten fatale Auswirkungen haben, wenn ein direkter Zugriff auf das Backend und die dort vorhandene Systemlandschaft möglich wäre.

Klassische Security-Maßnahmen

Zur Umsetzung dieser Anforderung gibt es eine Vielzahl von Möglichkeiten, etwa die Netzwerk-Segmentierung. Hier werden die einzelnen Bereiche auf Netzwerkebene voneinander getrennt und dann die Anwendungen auf die einzelnen virtuellen Netzwerke (VLANs) aufgeteilt. Über ein entsprechendes Routing und mit Hilfe von Firewall-Regeln lassen sich dann die erlaubten Kommunikationspfade zwischen den einzelnen Systemen und den darauf laufenden Anwendungen festlegen und steuern. Ein neues System in eine solche Landschaft zu integrieren, erfordert allerdings durchaus etwas Aufwand und ist oftmals ein manueller Prozess.

Ein weiterer Nachteil der Segmentierung auf Netzwerkebene besteht darin, dass es noch mehr Aufwand erfordert, wenn einzelne Anwendungen voneinander abgeschottet werden sollen – oder gar der Anspruch besteht, dass eine Anwendung auf System A nur mit einer ganz bestimmten Anwendung auf System B kommunizieren darf, nicht aber mit anderen Anwendungen auf diesem Host.

Unter Linux existieren für diese Anforderungen mehrere Lösungen. So implementiert das SELinux-Framework eine Form der Mandatory-Access-Control. Mit Hilfe von Labeln können Prozesse nur auf bestimmte Objekte, wie beispielsweise Dateien, zugreifen. Wie dieser Zugriff aussieht, definiert ein systemweites Regelwerk. Dieses Konzept lässt sich auf das gesamte Netzwerk ausweiten. So gibt es mit Netlabel [1] ein auf CIPSO [2] basierendes Modell, bei dem Netzwerkpakete mit einem Security-Label versehen werden. Anhand des erwähnten Regelwerks wird auch hier definiert, welcher Prozess auf welches Netzwerkpaket (und das damit verbundene Label) zugreifen darf. Einen ähnlichen Ansatz verfolgt das SECMARK-Projekt [3], das ebenfalls auf SELinux fußt und eng mit dem Kernel-basierten Netfilter-Framework zusammenarbeitet. Hier werden Netzwerkports und Schnittstellen mit einem bestimmten Security-Label versehen. Sämtliche Pakete, die über einen solchen Port oder Schnittstelle in das System gelangen, dürfen lediglich wieder nur an zuvor definierte Prozesse weitergeleitet werden. Die Prozesse werden ebenfalls mit Hilfe eines Security-Labels identifiziert und der Zugriff in einem Regelwerk festgehalten.

Bild 1: Mit Hilfe von Attributen identifiziert Trireme eine Anwendung und regelt den Zugang zu dieser auf Basis einer Network Policy.

Sonderfall Container

In klassischen Umgebungen, in denen nur eine Handvoll Anwendungsprozesse auf einem System laufen, ist dies durchaus alles umsetzbar. Schwierig wird es allerdings, sobald Container-basierte Lösungen zum Einsatz kommen. Hier ist es so, dass auf einem einzelnen System durchaus hunderte von unterschiedlichen Anwendungen laufen können. Die eingesetzte Container-Technologie sorgt dafür, dass die einzelnen Container jeweils einen eigenen Namespace verwenden und so voneinander isoliert sind. Somit bekommt jede Anwendung, die innerhalb eines Containers läuft, eine isolierte Sicht auf die vorhandenen Prozesse, das Netzwerk, die Dateisysteme und andere Bereiche des Systems.

Mittels SELinux wird zudem sichergestellt, dass die Ressourcen eines Containers nicht von einem anderen Container verwendet werden dürfen. Allerdings löst dies immer noch nicht das Problem auf Applikationsebene, wo jede Anwendung aus einem Container mit einer anderen Anwendung aus einem anderen Container kommunizieren kann. Klassische Methoden, wie eingangs dargestellt, funktionieren hier einfach nicht. Einen Container an ein VLAN zu hängen, um dadurch eine Segmentierung durchzuführen, ist nicht wirklich einfach, wenn gar nicht klar ist, auf welchem Host dieser Container gestartet wird.

Orchestrierungsframeworks wie Kubernetes kümmern sich in der Regel selbstständig darum, einen Container auf einem bestimmten Host zu starten. Welcher das ist, wird durch zuvor festgelegte Metriken definiert. So kümmert sich Kubernetes mit Hilfe von Replication-Controllern beispielsweise auch darum, wenn aufgrund einer erhöhten Last auf einer Anwendung zusätzliche Container mit eben dieser Anwendung gestartet werden müssen. In einer solchen Umgebung können Container durchaus im Sekundentakt gestartet und gestoppt werden. Nehmen Sie es mit dem Thema Security wirklich ernst, erfordert diese hohe Dynamik komplett neue Lösungswege.