Container sind durch den Kernel gekapselte Bereiche auf einem System und stellen isolierte Umgebungen für das Ausführen von Prozessen zur Verfügung. Der Grundgedanke ist es, fertige Bausteine für Applikationen zur Verfügung zu stellen. Container lassen sich aktuell nach verschiedenen Standards bauen: Docker, AppC oder der Urvater LXC sind hier zu nennen. Leider sind diese Standards nicht zueinander kompatibel. Durch die am 22. Juni 2015 gegründete Open Container Initiative keimt die begründete Hoffnung auf, dass sich hier in naher Zukunft ein gemeinsamer Standard etablieren wird. Nicht zuletzt, weil die Mitglieder aus zum Teil namhaften Vertretern der Szene bestehen.

Der Docker Hub - Risiken und Nebenwirkungen

Eine der großen Vereinfachungen, die Docker Entwicklern brachte, ist der Docker Hub. Er ermöglicht es, fertige Containerimages zu veröffentlichen und herunterzuladen. Das aber öffnet Tür und Tor, um auch manipulierte Containerimages zu verbreiten. Erst mit Docker 1.8 ist es überhaupt möglich, Images zu signieren. Für einen sicheren Betrieb ist es also unerlässlich, Images selbst zu erstellen und eine private Docker Registry zu betreiben. Dies schmälert aber aktuell leider noch die firmen- oder applikationsübergreifende Wiederverwendbarkeit.

Container Runtime - Herausforderung für die Security

Um lauffähig zu sein, benötigen Container eine Runtime, welche als Daemon auf dem Host läuft und den Lebenszyklus des Containers kontrolliert. Hier gibt es zwei nennenswerte Vertreter: Dockers runc und rkt, entwickelt von CoreOS. Technisch basieren die Runtimes auf zwei Konzepten des Linux-Kernels: Namespace Isolation und Control Groups. Diese ermöglichen es, bestimmte Prozessgruppen und Ressourcen voneinander zu isolieren, ähnlich Solaris Zones. In der Vollständigkeit dieser Isolation liegen weitere Herausforderungen in Bezug auf Sicherheit

• User Mapping

Da es keine User Namespaces gibt, werden aktuell UIDs von Dateien, die im Container zur Verfügung stehen, eins zu eins auf das Host System abgebildet. Dies ermöglicht es theoretisch, aus Containern Angriffe auf Dateien anderer User des Hostsystems zu starten.

• Zugriff auf kritische Host-Ressourcen

Docker Container greifen via Whitelist auf eine restriktive Menge von Kernel-Befehlen zu. Allerdings kann diese Liste mit Kernel-Verwundbarkeiten relativ einfach einen Ausbruch aus dem Container auf den Host ermöglichen, sofern nicht größte Sorgfalt bei der Konfiguration der Möglichkeiten angewendet wird. Hier fehlt es in der Community aktuell noch an Erfahrung für potentielle Angriffsvektoren sowie auch an Best Practices.

• Root-Rechte des Daemon: Der Daemon läuft mit root-Rechten und es gibt aktuell keine Möglichkeiten, rollenbasierte Einschränkungen der ausführbaren Befehle einzurichten. Daher ist es laut Docker ratsam, nur "vertrauenswürdigen Nutzern" den Zugriff zu ermöglichen. Ein rollenbasiertes Konzept und eine Aufteilung des Docker Daemons in privilegierte und nicht privilegierte Teile wäre hier wünschenswert.

Das Container-Ökosystem - der Markt ist unübersichtlich

Um Container sinnvoll für den Betrieb einer komplexen Applikation einsetzen zu können, ist es unabdingbar, mehrere Container miteinander zu verschalten und das entstehende Cluster zu verwalten. Auf diesem Gebiet ist der Markt noch sehr unübersichtlich. Man benötigt eine Vielzahl kleiner Tools, welche erst in Kombination einen stabilen Betrieb ermöglichen. Dabei ist zwischen folgenden Kategorien zu unterscheiden:

• Orchestrierung

Hierunter versteht man die Möglichkeiten, wie mehrere Container mit ihren Verbindungen zusammen beschrieben und deployed werden können. Die bekanntesten Vertreter sind Kubernetes, Apache Mesos sowie Docker Swarm und CoreOS fleet.

• Container Hosts

Spezielle minimale Betriebssysteme, die nur auf den Betrieb von Containern zugeschnitten sind, bezeichnet man als Container Hosts. Die bekanntesten Vertreter sind CoreOS, Atomic Host und Ubuntu Core.

• Networking

Wie können mehrere Container verteilt über verschiedene Hosts miteinander kommunizieren und wie kann man dies einfach nach IaC-(Infrastructure as Code) Richtlinien verwalten? CoreOS flannel oder das experimentelle Feature ab Docker 1.7 kommen hierfür infrage.

• Platform as a Service

PaaS Plattformen versprechen eine integrierte Lösung, die all die diskutierten Herausforderungen adressieren. Hier ist hauptsächlich OpenShift Origin in Version 3 zu nennen, welches auf Docker, Kubernetes und Atomic Host setzt.

Wenn man den Reifegrad der genannten Tools betrachtet, lässt sich feststellen, dass viele entweder in einem späten Beta-Stadium oder in einem ersten stabilen Release sind. Dies äußert sich in noch mangelnder Mandantenfähigkeit und Möglichkeiten zur Auditierung, was wiederum den breiten Einsatz in kontrollierten oder Mehrbenutzer-Umgebungen erschwert.

Fazit

Trotz der genannten Schwächen bieten Containertechnologien einen großen Fortschritt, um Continuous-Delivery- und DevOps-Bemühungen zu unterstützen. Die Geschwindigkeit, mit der in diesem Bereich die Weiterentwicklung vorangetrieben wird, legt nahe, dass in naher Zukunft auch bei den für einen Enterprise-Betrieb notwendigen Sicherheitsfunktionen ein Stand erreicht wird, der einen einfachen und flächendeckenden Einsatz von Containern ermöglicht.

Um auch heute schon diese Technologien einsetzen zu können, ist je nach Schutzbedarf eine Kombination mit klassischen Sicherheitsmechanismen vonnöten. Hier sollte die Trennung einer Applikation in verschiedene Schutzbereiche mindestens auf der Ebene von virtuellen Maschinen vorgenommen werden, die mit klassischen (virtualisierten) Firewalls voneinander getrennt werden. Denn aktuell ist es noch nicht sicher möglich, mehrere Schutzbereiche auf ein und demselben Containercluster zu betreiben. Das fehlende Rollenkonzept in der Runtime ermöglicht hier nur eine Trennung mit der Granularität von Hosts. Solche Funktionen sind ansatzweise schon in PaaS-Produkten wie etwa Red Hat OpenShift umgesetzt.

Zusammenfassend kann man sagen, dass Container eine vielversprechende Technologie sind, deren Mehrwert unumstritten ist. Leider rücken die Sicherheitsaspekte erst langsam in den Fokus der Entwickler. Deshalb müssen für den Einsatz in Produktivumgebungen im Moment noch teils erhebliche Mehraufwände investiert werden, um einen sicheren Betrieb zu gewährleisten. (wh)

Docker Container: Nützliche Links

Docker: http://docker.com

AppC: https://github.com/appc/spec/

LXC: https://linuxcontainers.org

Open Container Initiative: https://www.opencontainers.org

Docker 1.8. Release: https://blog.docker.com/2015/08/docker-1-8-content-trust-toolbox-registry-orchestration/

RunC: https://runc.io

rkt Container Runtime: https://github.com/coreos/rkt

CoreOS: https://coreos.com

Docker Security Documentation: http://docs.docker.com/articles/security/#docker-daemon-attack-surface

Kubernetes: http://kubernetes.io

Apache Mesos: http://mesos.apache.org

Dockor Swarm: https://www.docker.com/docker-swarm

fleet: https://coreos.com/using-coreos/clustering/

Atomic Host: http://www.projectatomic.io

Ubuntu Core: https://wiki.ubuntu.com/Core

flannel: https://github.com/coreos/flannel

OpenShift Origin: http://www.openshift.org/