Zu Zeiten der Cloud wird immer mehr auf Microservices umgestellt. Anwendungen laufen innerhalb isolierter Container, um Deployment und Management zu vereinfachen und sie sicherer zu machen. In der Arbeit werden vier Tools analysiert, die Docker-Images, -Container, beziehungsweise das Hostsystem auf deren Sicherheit überprüfen. Hierzu wird anhand eines kleinen Kriterienkatalogs deren Tauglichkeit im Bezug auf Nutzung, Umfang und Modularität ermittelt. Bei den getesteten Tools Clair, Lynis, Docker Bench for Security und Twistlock sticht vor allem Lynis sehr positiv heraus. Aber auch die kommerzielle Lösung Twistlock könnte im Unternehmenskontext von Interesse sein.
Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung - Keine Bearbeitungen 4.0 International Lizenz.
Einleitung
Im Zeitalter der “Cloud” und “DevOps” spielen Container eine wichtige Rolle. DevOps bezeichnet eine agile Methodik, welche Entwicklung (Development) und Betrieb (Operation) von Anwendungen und Diensten zusammenführen und diese schnell einsatzfähig machen soll. In diesem Zuge entstand zu den sich immer mehr virtualisierenden Infrastrukturen die Idee Anwendungen beziehungsweise Dienste in sich abgeschlossenen Instanzen laufen zu lassen, die man auch als Container bezeichnet.
Die Motivation dieser Arbeit ist es herauszufinden, welche Tools zur Sicherheitsanalyse einer Docker-Infrastruktur verfügbar sind und wie sie sich am besten in diese integrieren lassen. Anschließend soll ein Ergebnis geliefert werden können in welchem Kontext unterschiedliche Tool wie gut abschneiden. Weitergehend wird eine mögliche Toolchain der präsentierten Tools vorgestellt und wie man damit möglichst umfangreiche Auswertungen bezüglich der Sicherheit der Docker-Infrastruktur machen kann.
In den folgenden Abschnitten werden zunächst die Grundlagen der Containerisierung beleuchtet und anschließend Werkzeuge vorgestellt, welche bei der Analyse bezüglich der Sicherheit von laufenden Containern respektive statischen Images behilflich sein können.
Grundlagen
BSDs jails und Linux' chroot haben schon relativ frühzeitig Konzepte der Isolierung aufgegriffen und über system calls im Kernel implementiert. System calls sind Funktionen im Kernel, welche es möglich machen Anwendungen auf dem Betriebssystem Systemressourcen in Form einer Schnittstelle zugänglich zu machen [9].
Sicherheit durch Isolation
Isolation in der Informatik beschreibt das in sich geschlossene Arbeiten von Anwendungen ohne beziehungsweise mit sehr eingeschränkten Kommunikationsmöglichkeiten zu anderen Applikation. Innerhalb des isolierten Raums haben die Anwendungen alle (und bestenfalls nur die nötigsten) Komponenten zur Verfügung, damit sie lauffähig sind und ihren Zweck erfüllen. Das sorgt dafür, dass eventuell kompromittierte Anwendungen und deren laufende Prozesse durch die isolierte Charakteristik keine weiteren Prozesse beeinflussen können und somit eine Quarantänezone abbilden, die jederzeit beseitigt und wieder neu gestartet werden kann.
Abgrenzung zur Virtualisierung
Wie auch Joachim J. Włodarz in seinem wissenschaftlichen Text Virtualization: A double-edged sword [12] beschreibt, versteht man unter Virtualisierung das Bereitstellen virtualisierter Systemressourcen, wie beispielsweise der Festplatte, des RAMs, der CPU oder der GPU. Hierbei werden Entitäten des Hauptsystems erstellt, welche durch einen Hypervisor verwaltet werden. Jedes dieser Gast-Systeme stellt ein komplettes (virtualisiertes) Betriebssystem dar. Dieser Ansatz der Hardwarevirtualisierung wird auch als hypervisor-based virtualization bezeichnet und wird überwiegend in Rechenzentren verwendet um eine große Anzahl an Ressourcen aufzuteilen.
Ein anderer Ansatz der Virtualisierung ist die container-based virtualization oder Containerisierung. Hierbei teilen sich die Container einen gemeinsamen Kernel und die Virtualisierung beziehungsweise Containerisierung findet auf Betriebssystemebene statt, indem Prozesse isoliert verwaltet werden. Dieses Konzept findet vor allem beim Isolieren von Diensten wie Webservices oder Datenbanken Gebrauch.
Docker
Docker ist eine solche container-based virtualization und macht sich eine Reihe von Bibliotheken und Kernel-Modulen zu Nutze, um die Docker Engine zu implementieren. Diese sollten grundlegend verstanden werden, um das Konzept der Isolation und Containerisierung zu begreifen [10]:
cgroups ist ein Kontrollmechanismus für Prozesse, der diese hierarchisch organisiert und Systemressourcen aufgrund dieser Hierarchie verteilt [6].
namespaces abstrahieren globale Systemressourcen, sodass Prozesse innerhalb eines Namespaces ihre eigene isolierte Instanz jener globalen Ressource haben. Andere Prozesse desselben Namespaces haben Einsicht auf Änderungen dieser Ressource, nicht jedoch Prozesse außerhalb des Namespaces. Sie können benutzt werden um Container zu implementieren [8].
capabilities sind Attribute, welche pro Prozess aktiviert oder deaktiviert werden können. So hat nicht jeder Prozess, welcher als root läuft alle Privilegien, sondern nur die ihm zugewiesenen [7]. Das sorgt dafür, dass eine Schwachstelle nicht allzu gravierende Folgen hat und der infizierte Prozess eingeschränkt bleibt.
Docker Engine
Die Docker Engine ist eine Client-Server-Applikation und besteht aus drei wesentlichen Bestandteilen: dem Client, dem Server und einer REST-Schnittstelle über die via UNIX-Sockets oder einem Netzwerk-Interface eine Kommunikation hergestellt werden kann.
Die Architektur von Docker lässt sich im Detail auf der aktuellen Dokumentationsseite [4] finden. Die folgenden Punkte sind wichtig für das Verständnis und werden nun kurz anhand Abbildung nachfolgender erläutert.
Quelle: 
Images:
Templates, um einen Docker-Container zu erstellen, werden als Images bezeichnet. Diese Templates werden in so genannten Dockerfiles festgelegt und bestehen immer aus einem Basis-Image (zum Beispiel Debian, Ubuntu, Busybox, Alpine Linux, etc.) und Anweisungen in spezieller Docker-Syntax, um dieses Basis-Image mit Funktionalitäten zu füllen.
Container:
Die laufende Instanz eines solchen Docker-Images schließlich stellt den Docker Container dar. Man kann ihn über das Docker CLI starten, stoppen, löschen und hat weitere Steuerungsmöglichkeiten. Ein Container bildet eine isolierte Umgebung ab, in der bestimmte Anwendungen laufen. Diese isolierten Container können mit anderen Containern durch fest definierte Regeln miteinander kommunizieren und gegebenenfalls Daten auf dem Host schreiben und/oder lesen.
Registry:
Sie sammelt Docker-Images zur Verteilung und zum zentralem Management.
Docker Daemon:
Als Hauptbestandteil der Docker Engine läuft er auf einem Host als Daemon-Prozess. Der Daemon ist dafür zuständig die Ressourcen zu verteilen und die Docker-Infrastruktur als solche zu verwalten.
Docker Client:
Er ist das Frontend in Form der docker Binary als Command Line Interface (CLI), mit dem der Benutzer interagieren kann. Hier findet also die Steuerung der Docker-Container und -Images durch den Benutzer statt. Tabelle [docker-architektur] zeigt drei Befehle. Der Befehl docker build wird zum Erstellen der Images auf Basis einer Dockerfile verwendet, docker pull lädt Images aus einer angegebenen Registry herunter und docker run führt ein auf dem System vorhandenes Image als Container aus.
Docker Compose:
Falls man Mehrfach-Container-Anwendungen aufsetzen möchte, wird einem durch Docker Compose [5] das Aufsetzen vereinfacht. In einer YAML-Datei, die üblicherweise docker-compose.yml heißt, werden benötigte Docker Images definiert und Parameter wie gemountete Volumes oder Netzwerkeinstellungen festgelegt. Mit einem weiteren CLI kann man dann diese Mehrfach-Container-Anwendungen verwalten. Als einfaches Beispiel lässt sich hier ein Webserver mit angebundener Datenbank nennen.
Sicherheitsanalyse von Docker-Containern
Nachdem die Grundlagen des Isolierungskonzepts und die fundamentale Funktionsweise von Docker nun beschrieben wurden, wird erläutert, wie es mit der tatsächlichen Sicherheit um isolierte Docker-Container steht.
Potenzielle Gefahrenstellen in einer Container-Infrastruktur
Bevor auf die eigentlichen Tools zur Analyse der Sicherheit eingegangen wird, ist es wichtig zunächst generelle Gefahrenstellen einer solchen Container-Infrastruktur zu beleuchten.
Host
Selbstverständlich ist jedweder Versuch Applikationen abzusichern erfolglos, wenn das Host-System, auf dem die Container laufen, anfällig ist. Es sollte also in erster Linie dafür gesorgt werden, dass der Host durch regelmäßige Updates und Härtung des Systems weitestgehend abgesichert ist.
Virtualisierungslösung
Wie bereits anfangs erwähnt, wird heutzutage viel virtualisiert. Viele Rechenzentren beziehungsweise Cloudanbieter setzen auf Virtualisierungslösungen. An dieser Stelle muss dafür gesorgt werden, dass jener Hypervisor keine Schwachstellen aufweist.
Docker-Images
Sofern Host unsd gegebenenfalls die Virtualisierungsumgebung durch Maßnahmen gehärtet gegenüber Angriffen sind, sollten nur Docker-Images verwendet werden, denen man vertraut. Speziell Images, deren Dockerfile nicht quelloffen ist, sollte man mit Vorsicht betrachten und weitere Sicherheitsmaßnahmen in Erwägung ziehen.
Laufende Container
Schließlich bleiben die laufenden Container. Sofern diese nicht ordnungsgemäß gestartet wurden oder eventuell überflüssige Privilegien erhalten, können sie ein Sicherheitsrisiko darstellen.
Kriterien beim Analysieren der Tools
Die folgenden Tools werden anhand eines Kriterienkatalogs analysiert und schließlich eine Bewertung durchgeführt, um zum Schluss auswerten zu können füsr welche Fälle sich welche Tools mehr oder weniger eignen.
Kontext
Der Kontext soll definieren in welchem Umfeld das Tool arbeitet.
“Image” heißt hierbei, dass sich das Tool Informationen aus der Dockerfile und/oder der Image-Parameter zu Nutze macht, etwa über installierte Anwendungen, Netzwerkinstallationen, Environment-Variablen, etc.
“Container” bedeutet, dass das Tool aktiv den laufenden Container analysiert. Hier könnte man wohl von einer Art Penetrationstest sprechen, in dem versucht wird von “außen” (vom Host zum Container) die Anwendung anzugreifen. Genauso gut könnte man an dieser Stelle aber auch das jeweilige Tool in den laufenden Container mit einbringen, um beispielsweise laufende Prozesse innerhalb zu überwachen.
Zu guter Letzt weißt der Kontext “Host” darauf hin, dass das Tool den Host selbst unter die Lupe nimmt, um so zu ergründen, ob es Sicherheitsprobleme auf der Maschine gibt, auf der die Docker-Infrastruktur läuft.
Art
Hierbei wird zwischen “quelloffen” und “kommerziell” unterschieden. Ist ein Tool quelloffener Natur bedeutet dies, dass man es ohne Weiteres auf der eigenen Maschine aufsetzen und testen kann. Die kommerzielle Eigenschaft weist darauf hin, dass man zum Aufsetzen und Testen zunächst mit dem Entwickler in Kontakt treten muss und gegebenenfalls eine Lizenz benötigt. Weisen quelloffene Tools die Möglichkeit auf auch im Unternehmenskontext eingesetzt zu werden, wird diese Eigenschaft nicht zusätzlich gekennzeichnet.
Bewertung
Zur Bewertung werden die Kategorien in “positiv”, “neutral” und “negativ” unterteilt. Aufgrund der Individualität der Tools ist es schwer generell die Bewertungskriterien auf globaler Ebene zu beschreiben. Dies findet jedoch in der jeweiligen Beschreibung und Bewertung der einzelnen Tools statt. Die folgenden drei Kategorien werden als Bewertungsmaßstab herangezogen.
Nutzung:
Diese Kategorie bewertet den Aufwand des Einrichtens und die eigentliche Nutzung.
Umfang:
Er schließt mit ein, welche Formen der Ausgabe möglich sind und in welchem Detailgrad sie präsentiert werden.
Modularität:
Die Anzahl der Schnittstellen und die Möglichkeit das Tool in eine Pipeline mit einzubringen sind Faktoren die bei der Modularität mit einbezogen werden.
Tools
Clair
Clair ist ein in Go geschriebenes Tool zur statischen Analyse von unter anderem Docker-Containern. Hierzu werden im zu analysierenden Container installierte Pakete auf bekannte Schwachstellen gemäß CVE-Datenbanken überprüft [2].
Dank bereitgestellter docker-compose.yml in den offiziellen GitHub-Repositories ist Clair innerhalb weniger Minuten lauffähig. Darüber hinaus bietet es ein Referenz-Tool für die Kommandozeile, das ebenfalls über deren Repository verfügbar ist. Es setzt eine Go-Installation voraus und ist in der Lage zu Testzwecken relevante Ergebnisse direkt auf der Kommandozeile auszugeben.
Leider unterstützt Clair momentan nur Red Hat, Ubuntu und Debian CVEs. Clair bietet eine JSON-API mit Hilfe derer man beispielsweise Analyseergebnisse weiterverarbeiten kann, um sie etwa zu visualisieren.
Zusätzlich kann man Clair in eigene Registries verflechten und es direkt in eine Continuous-Integration-Pipeline einbinden.
Das Ergebnis wird in Tabelle folgender Tabelle zusammengefasst:
| Kontext | Image |
| Art | quelloffen |
| Nutzung | positiv |
| Umfang | negativ |
| Modularität | neutral |
Lynis
Lynis ist ein Security-Auditing-Tool, das in der Lage ist die Sicherheit eines unixartigen Betriebssystems (AIX, FreeBSD, HP-UX, Linux, macOS, NetBSD, OpenBSD, Solaris, …) [1] zu auditieren. Verbreitet wird es offiziell als Paket oder respektive über das GitHub-Repository als einfaches Shell-Script. Lynis ist in der Lage, sowohl den Host, den Container als auch das Image (über die Dockerfile) zu auditieren.
Zur Nutzung lässt sich sagen, dass es einfacher wohl nicht sein könnte. Entweder die Distribution bringt das Paket in ihren offiziellen Repositories mit: somit handelt es sich lediglich um die Installation und das Ausführen über das Shell-Script oder es lässt sich über GitHub beziehen und kann über das im Stammverzeichnis liegende Shell-Script lynis ausgeführt werden.
Zusätzlich verfügt Lynis über verschiedene Modi, wie zum Beispiel dem Auditieren des Host-Systems oder einer Dockerfile. Zudem gibt es Optionen wie dem “Pentest-Mode”, der als unprivilegierter Prozess versucht das System auf Schwachstellen zu überprüfen.
Lynis produziert zusätzlich zu der Ausgabe auf der Konsole ebenfalls Logs, welche sich beliebig weiterverarbeiten lassen können (zum Beispiel, um die Ergebnisse zu visualisieren oder Events bei kritischen Funden zu generieren).
Daraus folgt das Ergebnis, das in Tabelle nachfolgender Tabelle dargestellt wird.
| Kontext | Image Container Host |
| Art | quelloffen |
| Nutzung | positiv |
| Umfang | positiv |
| Modularität | neutral |
Docker Bench for Security
Docker Bench for Security untersucht den Host, Images und laufende Container auf Best-Practices. Das Shell-Script lässt sich via GitHub [3] herunterladen und ausführen.
Das Tool ist lauffähig, sobald das Script aus dem GitHub-Repository heruntergeladen wurde und lässt sich ohne weitere Parameter ausführen.
Docker Bench for Security gibt die Ergebnisse direkt auf der Konsole aus. Mit einem weiteren Parameter werden die Ergebnisse in einen Log geschrieben. Dort prüft es zunächst Docker-Parameter auf dem Host, wie der installierten Version oder den Rechten auf Docker-Dateien und -Verzeichnisse. Anschließend wird der Docker-Daemon untersucht und beispielsweise überprüft, wie es um die Netzwerkkonfiguration der Docker-Infrastruktur steht. Weiterhin werden namespaces und cgroups auf Korrektheit getestet. Schließlich werden dann installierte Images und laufende Container genauer unter die Lupe genommen. Es gibt leider keine Möglichkeit eigene Policies zu definieren und so kommt es vor, dass Warnmeldungen ausgegeben werden, bei denen andere Sicherheitsmaßnahmen getroffen wurden.
Leider bietet Docker Bench for Security keine weiteren Ausgabemöglichkeiten und man ist an die standardmäßige Textausgabe gebunden. An dieser Stelle ist das Tool wohl nicht für weitere Nutzung geeignet und stellt an sich ein reines Standalone-Script dar.
Daraus folgt das Ergebnis in dieser Tabelle:
| Kontext | Image Container Host |
| Art | quelloffen |
| Nutzung | positiv |
| Umfang | neutral |
| Modularität | negativ |
Twistlock
Twistlock stellt eine Out-of-the-Box Platform für unter anderem Docker-Infrastrukturen bereit. Sie existiert in zwei Versionen: Einer kleinen Entwicklerversion und der großen Enterprise-Version mit vollem Funktionsumfang.
Durch die proprietäre und zu dem kommerzielle Natur von Twistlock ist es leider nicht einfach möglich eine Testumgebung zum Laufen zu bringen. Es ist nötig sich auf der Entwicklerseite zu registrieren, um eine Entwicklerlizenz zu erhalten. Das macht das Aufsetzen nicht nur umständlich, sondern zudem zeitaufwändig, da auf eine Antwort der Hersteller gewartet werden muss.
Bezüglich des Umfangs lässt sich über die Entwicklerseite [11] einiges in Erfahrung bringen: So soll Twistlock viele Use-Cases bieten, die es zu einer umfangreichen Lösung machen. Twistlock scheint in der Lage zu sein zur Laufzeit der Container diese auf Anomalien im Verhalten zu untersuchen und Verstöße gegen Policies zu melden. Weitergehend soll Twistlock die Möglichkeit bieten Images in Registries und auf lokalen Maschinen auf bekannte Verwundbarkeiten zu testen. An dieser Stelle ist das Tool vielen quelloffenen Alternativen voraus, da es zu Open-Source-Threat-Intelligence-Quellen des Weiteren proprietäre und herstellerabhängige Threat-Intelligence-Quellen hinzufügt. Überdies verfügt Twistlock laut Entwickler über eine CI-Integration.
Die Entwickler geben auf ihrer Website bekannt, Twistlock sei sehr umfangreich über eine API bedienbar. Das mache Automation, CI-Integration, Auto-Skalierung, Zugriffskontrolle, benutzerdefinierte Reports, etc. möglich.
In zusammegefasster Ausführung finden sich die Ergebnisse in nachstehender Tabelle.
| Kontext | Image Container Host |
| Art | kommerziell |
| Nutzung | negativ |
| Umfang | positiv |
| Modularität | positiv |
Ergebnisse und Grenzen
Zur Bewertung werden zunächst die Kategorien “Nutzung”, “Umfang” und “Modularität” herangezogen, ohne Berücksichtigung des Kontextes oder der Art. Das hat den Grund, dass eine Gesamtbewertung beziehungsweise die Eignung eines Tools sehr abhängig davon ist, für welchen Zweck man es einsetzt. Um nun die Ergebnisse der Tools in den genannten Kategorien zu bestimmen, wird “positiv” als +1, “neutral” als 0 und “negativ” als -1 gewertet. Daraus gehen die Ergebnisse aus nachstehender Tabelle hervor.
| Tool | Clair | Lynis | Docker Bench for Security | Twistlock |
| Note | 0 (neutral) | 2 (positiv) | 0 (neutral) | 2 (positiv) |
| Kontext | Image | Image Container Host | Image Container Host | Image Container |
Man kann sagen, dass Lynis wohl das mit Abstand umfangreichste Tool ist, was aber nicht bedeutet, dass es auch für alle Zwecke Einsatz findet. Sein Hauptaugenmerk liegt auf dem Host, was heißt, dass es per se nicht für Docker entwickelt wurde. Man kann an dieser Stelle jedoch sagen, dass es universell einsetzbar ist. Was auf einem Host analysiert werden kann, kann man ebenso in einem Container untersuchen.
Auch Clair verliert nicht seine Daseinsberechtigung, da es sich perfekt eignet, um Images in der eigenen Registry vor einer Aktualisierung auf bekannte Schwachstellen zu überprüfen. Auch wenn es aktuell nur Debian, Ubuntu und Red-Hat als Base-Images unterstützt, sollte man Clair nicht aus den Augen verlieren.
Docker Bench for Security eignet sich leider nur wirklich im Prozess der Entwicklung von Dockerfiles. Jedoch ist es hierbei sehr nützlich, um bekannte Fehler schnell zu beheben und sich an Best-Practices zu halten.
Ist man im Besitz der monetären Mittel ist Twistlock sicherlich eine Lösung, die man sich genauer anschauen kann. Man sollte sich an dieser Stelle allerdings bewusst sein, dass mit Software as a Service (SaaS) Abhängigkeiten geschaffen werden. Für Unternehmen, welche keine Infrastruktur für eine eigene Registry und den nötigen Continuous-Integration-Pipelines zur Verfügung haben, könnte Twistlock jedoch eine relativ gute Lösung sein.
Für den Privatgebrauch kann man sich relativ einfach aus den vorgestellten Tools eine solide Toolchain zusammenstellen: In der Entwicklungsphase einer Docker-Infrastruktur und dem damit zusammenhängenden Prozess des Schreibens von Dockerfiles und Docker-Compose Dateien lässt sich mithilfe von Docker Bench for Security auf regelmäßiger Basis manuell via Script auf bekannte Fehler überprüfen. Waren alle Tests erfolgreich ist es nun möglich die neu geschriebene oder aktualisierte Dockerfile in die eigene Registry hochzuladen. In diesem Prozess kann Clair unterstützend wirken und das hochgeladene Image auf Schwachstellen überprüfen, indem es in eine Continuous-Integration-Pipeline eingebunden wird. Möchte man zudem die laufenden Container evaluieren, kann man beim Starten des Containers das Lynis-Script laufen lassen und gegebenenfalls dessen Logs weiter auswerten. Auch die Sicherheit des Hostsystems sollte an dieser Stelle nicht verkannt werden: Auch hier kann man auf regelmäßiger Basis (via Cronjobs beispielsweise) Lynis-Scans laufen lassen.
Allgemein ist klarzumachen, dass die getesteten Tools nur im Rahmen aussagekräftig sind, für den sie entwickelt wurden. Es bedarf meistens einer zusätzlichen Bewertung durch einen Fachkundigen, der mit den Betriebsbedingungen der Container vertraut ist.
Zusammenfassung
Die Motivation dieser Arbeit war es Sicherheitsanalysetools für eine Docker-Infrastruktur ausfindig zu machen und herauszufinden, wie sich diese am besten in diese integrieren lassen.
Es hat sich herausgestellt, dass man sämtlichen getesteten Tools eine rein unterstützende Rolle zuschreiben kann. Das ist vor allem dann relevant, wenn es um eine Vergleichbarkeit bei Aktualisierungen der Container beziehungsweise Images geht.
Sind die nötigen Kenntnisse vorhanden lässt sich mit den vorgestellten Tools vergleichsweise einfach eine sichere Docker-Infrastruktur zusammenstellen und sie in bereits vorhandene Pipelines einpflegen.
Möchte man sich den Aufwand des Aufsetzens einer solchen Infrastruktur nicht machen und/oder fehlen an dieser Stelle die Kenntnisse hilft eventuell Twistlock als kommerzielle Alternative aus. Besonders für Unternehmen ist diese Lösung möglicherweise attraktiver.
Literatur
[1] CISOfy. Lynis Documentation
URL: https://cisofy.com/documentation/lynis/
(besucht am 09. 03. 2017)
[2] CoreOS. Clair v1 API
URL: https://coreos.com/clair/docs/latest/api_v1.html
(besucht am 08. 03. 2017)
[3] Docker Inc. Docker Bench for Security
URL: https://github.com/docker/docker-bench-security
(besucht am 10. 03. 2017)
[4] Docker Inc. Docker Overview
URL: https://docs.docker.com/engine/understanding-docker/
(besucht am 08. 03. 2017)
[5] Docker Inc. Overview of Docker Compose
URL: https://docs.docker.com/compose/overview/
(besucht am 08. 03. 2017)
[6] Tejun Heo. Control Group v2
URL: https://www.kernel.org/doc/Documentation/cgroup-v2.txt
(besucht am 07. 03. 2017)
[7] Michael Kerrisk. capabilities - overview of Linux capabilities
URL: http://man7.org/linux/man-pages/man7/capabilities.7.html
(besucht am 07. 03. 2017)
[8] Michael Kerrisk. namespaces - overview of Linux namespaces
URL: http://man7.org/linux/man-pages/man7/namespaces.7.html
(besucht am 07. 03. 2017)
[9] Michael Kerrisk. syscalls - Linux system calls
URL: http://man7.org/linux/man-pages/man2/syscalls.2.html
(besucht am 08. 03. 2017)
[10] Jeff Nickoloff. Docker in Action
Hrsg. von Manning Publications Co. 2016.
[11] Twistlock Ltd. Use Cases
URL: https://www.twistlock.com/use-cases/
(besucht am 13. 03. 2017)
[12] Joachim J. Włodarz. Virtualization: A double-edged sword
17. Sep. 2017