Überblick Sandboxed-Container

Aktuelle Container-Technologien haben Schwächen in der Isolation

Aktuelle Container-Technologien haben Schwächen in der Isolation

Überblick zu Sandboxed-Container-Technologien

Unit 42, das Security-Forschungsteam von Palo Alto Networks, hat mehrere Lösungen begutachtet, die das Problem der schwachen Isolation der aktuellen Containertechnologie angehen. Die Erkenntnisse sind im Forschungsbericht „Making Containers More Isolated: An Overview of Sandboxed Container Technologies” zusammengefasst.

Gängige Container wie Docker, Linux Containers (LXC) und Rocket (rkt) werden nicht unbedingt nach dem Sandboxed-Prinzip betrieben, da sie den Host-Betriebssystemkern teilen. Sie sind ressourceneffizient, aber die Angriffsfläche und die potenziellen Auswirkungen eines Angriffs sind immer noch zu groß. Dies gilt insbesondere in einer mandantenfähigen Cloud-Umgebung, in der Container verschiedener Kunden gemeinsam platziert werden.

Während sich die Mehrheit der IT-Branche auf Cloud-native Lösungen zubewegt, ist es unerlässlich, die Grenzen der Technologie zu verstehen. Es wurde geforscht und entwickelt, um wirklich Sandboxed-Container zu entwickeln. Bei den meisten dieser Lösungen wurde die Grenze zwischen den Anwendungen umgestaltet, um die Isolation zu verstärken.

Unit 42 hat sich vier Lösungen näher angesehen, die verschiedene Techniken verwenden, um das gleiche Ziel zu erreichen. IBM Nabla baut Container auf Grundlage von Uni-Kernels, Google gVisor erstellt einen spezialisierten Gast-Kernel für den Betrieb von Containern, Amazon Firecracker ist ein extrem 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: Es fällt schwer zu bewerten, welche Lösung am besten funktioniert, da sie alle unterschiedliche Vor- und Nachteile haben:

  • IBM Nabla ist 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 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 ist ein 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.

Laut Einschätzung von Unit 42 dürfte es einige Zeit dauern, bis eine oder mehrere Lösungen vom Mainstream angenommen werden. Es ist jedoch positiv zu sehen, 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 effektiv reduzieren.