Container-Isolation erhöht die Sicherheit

Bei Container-Systeme wie Docker, Linux Containers (LXC) und Rocket (rkt) ist eine gewisse Abgrenzung der Container voneinander gegeben, trotzdem teilen sich alle auf dem System vorhandenen Container-Instanzen einen Kernel. Eine verbesserte Isolation der einzelnen Containergilt als essentiell, um die Sicherheit der Daten  zu erhöhen.

Im DevOps-Bereich haben sich Container als ressourceneffizient, gut skalierbar, schnell austauschbar erwiesen. Zudem liefern sie den Administratoren, Entwicklern und Mitarbeitern in den Unternehmen eine hohe Flexibilität: Ist ein Container defekt, oder nicht aktuell, lässt sich dieser mit wenig Aufwand entfernen, und durch einen aktuellen Container, der den Anforderungen entspricht, tauschen.

Aber auch einige Nachteile gehen mit der Container-Technologie einher. Während ein Bare-Metal-System exklusiven Zugriff auf die Hardware ermöglicht, wird meist eine große Anzahl an Containern auf einem physikalischen System betrieben. Das ist zunächst mit mehreren VMs (virtuelle Maschinen) zu vergleichen, allerdings verfügen VMs über ein eigenes Gast-betriebssystem und damit über eigene Betriebssystem-Kernel.

Container dagegen teilen sich  einen OS-Kernel und werden auf ein und derselben Hardware betrieben. Das erhöht die Angriffsfläche und die potenziellen Auswirkungen von Hacking-Attacken. Dies gilt insbesondere in einer mehr-mandantenfähigen Cloud-Umgebung, in der Container verschiedenster Kunden gemeinsam auf einem Hostsystem betrieben werden.

Ein Lösungsweg ist, alle Container in einer eigenen „Sandbox“ zu betreiben, und diese entsprechend voneinander abzuschotten. Alternativ könnte man auf jedem physikalischen System nur einen Container betreiben, aber dies würde alle Vorteile der Container-Plattform negieren. Bei den Sandboxed-Containern wurde die Grenze zwischen den Anwendungen umgestaltet, um die Isolation zu verstärken, auch wenn sich diese immer noch auf dem selben Host befinden.

Das Forschungsteam Unit 42 von Palo Alto Networks hat in diesem Zusammenhang mehrere Lösungen in Augenschein genommen. Das Problem der schwachen Isolation der aktuellen Containertechnologie wird dabei unterschiedlich angegangen. Die Erkenntnisse sind im Forschungsbericht „Making Containers More Isolated: An Overview of Sandboxed Container Technologies” zusammengefasst.

Vier der Lösungen nutzen verschiedene Techniken, um das gleiche Ziel zu erreichen. Dabei versucht IBM Nabla Container auf Grundlage von Uni-Kernels aufzubauen, Google gVisor positioniert einen spezialisierten Gast-Kernel für den Betrieb von Containern, Amazon Firecracker zeigt sich als schlanker Hypervisor für Sandboxing-Anwendungen und OpenStack platziert Container in einer speziellen VM, die für Container-Orchestrationsplattformen optimiert ist. Das Fazit der Sicherheitsforscher lautet: Alle Lösungen weisen unterschiedliche Vor- und Nachteile bei unterschiedlichen Einsatzszenarien auf:

• Beim IBM Nabla handelt es sich um eine Uni-Kernel-basierte Lösung, die Anwendungen in einer spezialisierten VM bündelt. Nabla ist empfehlenswert, wenn Anwendungen in Uni-Kernels wie MirageOS oder IncludeOS ausgeführt werden.
• Google gVisor ist ein Zusammenschluss eines spezialisierten Hypervisors und eines Gastbetriebssystemkerns, der eine entsprechend sichere Schnittstelle zwischen den Anwendungen und ihrem Host bietet. gVisor ist derzeit am besten mit Docker und Kubernetes integriert, aber aufgrund seiner unvollständigen Abdeckung von Systemaufrufen können einige Anwendungen immer noch nicht darauf ausgeführt werden.
• Amazon Firecracker gilt als spezialisierter Hypervisor, der jedem Gastbetriebssystem einen minimalen Satz an Hardware- und Kernelressourcen bereitstellt. Firecracker unterstützt benutzerdefinierte Gastbetriebssystem-Images, daher ist es eine gute Wahl, wenn Anwendungen in einer benutzerdefinierten VM ausgeführt werden müssen.
• OpenStack Kata ist eine hochoptimierte VM mit integrierter Container-Engine, die auf Hypervisoren laufen kann. Kata-Container sind voll kompatibel mit dem OCI-Standard und können sowohl auf KVM- als auch auf Xen-Hypervisor ausgeführt werden. Dies kann die Bereitstellung von Mikroservices in einer Umgebung mit hybriden Plattformen vereinfachen.

Es ist auf jeden Fall ersichtlich, dass die meisten Cloud-Anbieter aktiv geworden sind, um das Problem zu entschärfen. Für Unternehmen, die lokale Cloud-basierte Plattformen aufbauen, gibt es Abhilfemaßnahmen. Gängige Verfahren wie schnelles Patchen, Konfiguration mit geringsten Rechten und Netzwerksegmentierung können die Angriffsfläche ebenfalls effektiv reduzieren. Um die einzelnen Container noch besser voneinander abzugrenzen, sollten die Systembetreuer einen Blick auf die entsprechenden Lösungen werfen, und die jeweilig passenden Lösungen im eigenen Unternehmen ausrollen. (fah)

Palo Alto Networks