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.
- Docker-Bridge
Ohne die Eingabe zusätzlicher Konfigurationsparameter erzeugt Docker beim Start ein Standardnetzwerk auf der Basis der docker0-Bridge; diese leitet Datenpakete nur zwischen direkt angeschlossenen Schnittstellen weiter; so sind die Container zwar von dem lokalen Hostsystem, aber nicht von Außen erreichbar. - Docker-PortMapping
Port-Mapping: Der erste und zweite Container sind über jeweils einen eigenen DNAT-Port des Host-Systems (aus dem Bereich 49153-65535) und die docker0-Bridge von Außen erreichbar; die Verfügbarkeit des dritten Containers im Netzwerk beschränkt sich auf das Hostsystem und die Container der eigenen Docker-Instanz. - Open vSwitch-Bridge
Wer seine Arbeit nicht im Blindflug verrichten möchte, kann überprüfen, dass die neue Bridge wunschgemäß erzeugt wurde. - Open vSwitch-Masquerade
In der Standardkonfiguration routet die Docker-Brücke nicht nach Außen hin; Open vSwitch verleiht allen ausgehenden Paketen die Identität des Routers. - OpenvSwitch
Eine Beispielkonfiguration von Docker unter Verwendung von Open vSwitch für die Host-übergreifende Vernetzung von Containern. - Flannel
Ablauf der Kommunikation zwischen Docker-Containern auf zwei verschiedenen Hosts unter Verwendung von flannel. - Weave
Weave-Router auf verschiedenen Hosts sehen sich als gleichberechtigte Kommunikationspartner (so genannte Peers). - Weave-Container
Mit dem Befehl ifconfig im Inneren des Containers lässt sich die Existenz einer von Weave erstellten Netzwerkschnittstelle mit der Bezeichnung ethwe bestätigen. - Weave Ping auf AWS
Der Docker-Container 42f519bf8e94 auf einem EC2-Host (ip-15-0-0-104) pingt über ein virtuelles Weave-Netzwerk einen anderen Ubuntu-Container (8ce9c00e4aaf) an, welches auf einem entfernten EC2-Host (ip-15-0-0-23) im gleichen Subnetz einer virtuellen privaten Cloud (VPC) auf AWS läuft. - Weave Ping
Beispiel eines Pings auf AWS.. - Schnelleinstieg in AWS
Eine weiter gehende Einführung in Amazon Web Services (AWS) bietet das Werk „Schnelleinstieg in AWS: Amazon Web Services auf den Punkt gebracht. EC2-Administration im Schnellverfahren“
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/