Container in Unsicherheit Sind miniaturisierte virtuelle Maschinen die Infrastruktur der Zukunft?

Container-Infrastrukturen sind flexibel, skalierbar und schnell, aber letztlich unsicher. Als Ausweg bietet sich an, sie in besonders leichtgewichtige virtuelle Maschinen zu packen. OpenStack hat hierzu ein Projekt aufgelegt.

Anbieter zum Thema

Schwarz IT KG

Cloudgermany.de GmbH

emma technologies S.a.r.l.

In den Rechenzentren war die virtuelle Maschine längere Zeit das Maß der Dinge. Nun machen Container diesem virtuellen Konstrukt den Rang streitig. Tatsächlich sprechen einige Vorteile dafür, Container-Infrastrukturen aufzubauen: Schnelligkeit, Flexibilität und einfacheres Management von Abhängigkeiten.

Ein Container greift direkt auf die Container-Engine zu, die auf dem Betriebssystem aufliegt. Ein separater Hypervisor ist unnötig. Jeder Container enthält alles, was eine Software braucht, um zu laufen, also Code, Runtime, Tools und Systembibliotheken. Automatisch werden Abhängigkeiten berücksichtigt. Damit entfallen viele Konfigurationsprobleme, die beim Verschieben virtueller Maschinen auftauchen können.

So weit, so gut. Doch Container haben auch Probleme: So können sie nicht mit persistenten Daten umgehen, dafür sind technische Erweiterungen erforderlich. Und ihre Sicherheit ist geringer als häufig angenommen, denn Host und Container nutzen denselben Betriebssystem-Kernel.

Container bieten Angriffsfläche

Tatsächlich gibt es in Container-Infrastrukturen eine Reihe von Angriffsvektoren (siehe: Abbildung 1). Auf der Veranstaltung „Open Munich“ in diesem Februar zählte Referent Jan Willies von Accenture sie auf.

Beispielsweise können sich Angriffe direkt auf den Container richten (1), es können unautorisierte Netzwerkverbindungen bestehen (2) und die Worker-Knoten, auf denen die Container liegen, können erfolgreich angegriffen werden (3). Angreifer können aber auch direkt Kubernetes attackieren, beispielsweise die Steuerungsschicht (4), die „etcd“-Datenbank, in der sich alle relevanten Daten zum Kubernetes-Clouster befinden (5). Hat jemand entsprechende Zugriffsrechte erschlichen, können unerlaubt Container installiert (6) oder auf Applikationen zugegriffen werden (7).

Dieser Zustand ist naturgemäß unbefriedigend, insbesondere, wenn es sich um geschäftswichtige IT-Umgebungen handelt. Bislang bildet der Container-Cluster in „Kubernetes“/ „Docker“-Umgebungen eine Vertrauensgrenze. „Mit den üblichen Container-Sicherheitsmechanismen sollten Sie allen, die auf denselben Cluster zugreifen, besser vollständig vertrauen!“, fordert Willies.

Doch wann ist das schon der Fall, zumal viele Angriffe auf Unternehmensinfrastrukturen und -daten aus dem Inneren der Firmen kommen statt von außen. So verzeichneten nach dem „Insider Threat Report 2018“ des Marktforschungsunternehmens Crowd Research Partners 53 Prozent der befragten Unternehmen innerhalb der vergangenen zwölf Monate Insider-Attacken.

Sicherheitsfunktionen in Kubernetes-Umgebungen

Dennoch sind Anwender in Kubernetes nicht jedem Angriff schutzlos ausgeliefert. Vielmehr gibt es Abwehr- und Schutzmaßnahmen auf unterschiedlichen Ebenen. So kann man den Zugriff auf das Befehlszeilen-Tool „kubectl“ beschränken, rollenbasierte Zugriffs- und Netzregeln mit einer begrenzten Zahl von Rollentypen – Willies empfiehlt lediglich vier - definieren oder TLS im Bootstrap-Verfahren hochfahren.

Das Dashboard lässt sich deaktivieren, Service-Account-Tokens ebenso. Die Metadaten zu den Knoten können besonders geschützt und Images nach Sicherheitslöchern abgesucht werden. Nötig ist es auch, das Betriebssystem zu minimieren, Kubernetes regelmäßig zu aktualisieren, Management-Rollen auf das Nötigste zu beschränken, Audit-Logs anzufertigen und ausgelieferte Binaries vor der Installation zu überprüfen.

Schließlich sollten Microservices sauber voneinander getrennt werden, um die Wirkung kompromittierter Mikroservices zu limitieren. Dazu sollte jeder Pod eigene Sicherheitsregeln besitzen und Authentisierung sowie Verschlüsselung über ein Service Mesh erfolgen. Sinnvoll ist es, für Services unterschiedliche Namensräume zum Mounten, für das Netz und für Prozesse zu verwenden. Es könnte auch nötig sein, Pods in Sandboxen zu isolieren.

Die einzige Alternative: Abschotten?

Wer wirklich sichergehen soll, sollte Nutzer eines Clusters, die als unsicher eingestuft werden, in einem neuen Cluster unterbringen. Dann könnte am Ende jede Workload ihren Cluster und ihr Management-Team habe. Allerdings dürfte das sehr schnell umständlich und unübersichtlich werden.

Die Frage lautet daher: Gibt es einen Mittelweg zwischen Abschottung im eigenen Cluster und gemeinsamen Clustern mit ihren Sicherheitsrisiken?

Für diese Herausforderung scheint sich gerade ein neues Modell zu etablieren, wobei, wie derzeit üblich, Open-Source-Schmieden und Hyperscaler vorangehen: der Mikro-Container. Ein Beispiel dafür ist das relativ neue Open-Source-Projekt „Kata Containers“ (siehe: Abbildung 2), das seit Mai 2018 in Version 1.0 von Github heruntergeladen werden kann. Inzwischen gibt es Version 1.5, was zeigt, dass hier viel getan wird.

Die OpenStack-Idee: Kata Containers

Kata Containers, ein Projekt im Rahmen von OpenStack, kombiniert die Technologie von „Intel Clear Containers“ und „Hyper run V“. Im Grunde handelt es sich um Einheiten, die sich für den Anwender wie Container anfühlen, aber die Sicherheits- und Isolierungsvorteile virtueller Maschinen bieten.

Das Projekt hat sechs Komponenten: „Agent“, „Runtime“, „Proxy“, „Shim“, „Kernel“ und Paketierung gemäß „QEMU“ (Quick Emulator) 2.11. Letzteres ist eine Virtualisierungssoftware, die das Vorhandensein einer kompletten Computer-Hardware vorspiegelt. Emuliert werden beispielsweise x86, Power PC, ARM und viele andere, so dass eine Software mit QEMU auf einem anderen „Wirtsprozessor“ so läuft wie auf dem emulierten System.

Kata ist zudem kompatibel zu den Standards der Open Container Initiative. Das bedeutet, dass Durchlässigkeit zu Docker und Kubernetes gegeben ist. Die relevante Lizenz ist Apache 2.0.

Die Initiativen der Hyperscaler

Auch die Hyperscaler ergreifen Initiativen in diesem Bereich. So setzt Google mit „Gvisor“ auf eine Technologie, die Container in Sandboxen ausführt, deren Möglichkeit, Systemaufrufe an den Kernel zu senden, beschränkt wird. Bisher wurden auf virtuellen Maschinen unabhängige Gast-Kernel aufgesetzt, auf denen dann die Container mit den Applikationen liefen.

„AWS Firecracker“ schließlich, eine Open-Source-Initiative, die AWS im vergangenen Jahr vorstellte, verwendet einen auf KVM aufsetzenden Host User Space, auf dem „microVMs“ zusammen mit einem speziellen Orchestrator dem „Firecracker Orchestrator“, laufen. In nicht virtualisierten Umgebungen lassen sich die Mikro-VMs innerhalb von Mikrosekunden hoch- und wieder herunterfahren. Pro microVM sind nur 5 MiB (Mebibyte, eine auf exakten Bytes mit 8 Bit und entsprechenden Vielfachen - ohne Rundungsfehler - aufbauende Einheit).

Auf der Firecracker-VM laufen Gastfunktionen, denen nur ein rudimentäres Set an Komponenten angeboten wird: Vernetzungsmöglichkeiten, Block-I/O, ein Timer, der Systemtakt der KVM-Umgebung, eine serielle Konsole und genau die Tasten einer Tastatur, die für einen Reset der VM nötig sind. Das senkt die Angriffsfläche.

Fazit

Angesichts dieser Entwicklungen scheint es nicht zu weit hergeholt, wenn Willies zu dem Schluss kommt: „Virtuelle Maschinen könnten sich als die neuen Container entpuppen.“ Schließlich ist es beinahe die Regel, dass erfolgreiche Technologien aus der Open-Source- und Hyperscaler-Welt schnell den Weg auch in Unternehmensrechenzentren finden – besonders in der Ära der Hybrid Cloud.

* Ariane Rüdiger ist freie Journalistin uns lebt in München.

(ID:45757829)