Unternehmen sind zunehmend dabei, Container-Technologie einzusetzen und binden unter anderem Docker in ihren Technologie-Stack ein. Was als entwicklungszentrierter Ansatz startet, wird sich früher oder später auf produktive Umgebungen auswirken. Die Anzahl sicherheitskritischer Bedenken ist hoch, deshalb sollten Betriebs-Teams und Mitarbeiter mit DevOps-Hintergrund gut auf den produktiven Docker-Einsatz vorbereitet sein. Da ist es von Vorteil, dass die Docker Engine viele Stellschrauben besitzt, um die Sicherheit zu erhöhen. Bestehende Blog-Beiträge bieten Links zu unterschiedlichen Artikeln, wie eine bestehende Docker-Umgebung abgesichert werden kann. Leider kann man sich im Dschungel der unterschiedlichen Vorträge, Tipps und Erfahrungsberichte zur Konfiguration von Docker Daemon, Images und Containern schnell verirren. Der Artikel zeigt, auf welche Aspekte man beim Aufbau eines Systems achten sollte.

Dieser Artikel konzentriert sich auf Server-Systeme und Docker-bezogene Sicherheitsfunktionen. Zwar sind die Aspekte der Netzwerkschicht ebenso wichtig, werden allerdings in diesem Artikel aus Platzgründen nicht weiter betrachtet. Elementare Sicherungsmaßnahmen die bei der Arbeit mit Docker in Produktivumgebungen Berücksichtigung finden sollten stehen im Vordergrund. Dabei betrachten wir am Anfang den Host selber und stellen Härtungsmöglichkeiten vor, um in der Folge den Docker Daemon abzusichern. Docker ist vor allem deshalb beliebt, weil sich vom öffentlichen Docker Hub vorgefertigte Images herunterladen und als Container starten lassen. Daher gibt es „Best Practices“, um die Absicherung der Docker-Images behandeln. Der Artikel beschäftigt sich ebenfalls mit produktiven Containern und beschreibt die zur Laufzeit verfügbaren Parameter zur Verbesserung der Sicherheit. Abschließend werden Werkzeuge für das Monitoring einer produktiv umgesetzten Sicherheitskonfiguration vorgestellt.

Sicherung des Hosts

Als erstes sollte der Server, auf dem die Container laufen, gehärtet werden. Ziel ist es dabei, die Angriffsvektoren auf das Host-System selbst zu minimieren, da auf diesem Container unterschiedlicher Teams oder Kunden laufen können. Durch einen Ausbruch aus einem Container aufgrund einer Sicherheitslücke wären indirekt alle Container auf einem Host-System von dieser Lücke betroffen.

Um den Host abzusichern, sollten allgemeine Schritte der Systemhärtung, vor allem das Entfernen von überflüssigen

Diensten und Paketen durchgeführt werden. Dies reduziert die Angriffsfläche und minimiert die Möglichkeiten, die Angreifer nutzen könnten. Es gibt bereits Tools, die die Entfernung überflüssiger Dienste durchführen, z.B. OpenSCAP, und die Entwicklung neuer Tools steht nicht still. Als Beispiele seien [hardening.io] und [Lynis] genannt.

Container, die auf einem Host-Server laufen, nutzen den gleichen Kernel. Daher ist es sinnvoll, den Kernel selbst zu härten. Der Linux-Kernel ist komplex und enthält einige Module, die bei einem ggf. virtualisierten Server-System nicht notwendig sind. [GRSecurity] bietet Patches für den Linux-Kernel an, die eine Härtung des Kernel-Codes selbst ermöglichen. Die Patches werden bei einem Vanilla-Kernel, also dem unmodifizierten Code von kernel.org ohne die Ergänzungen von Linux-Distributionen, manuell angewandt, danach wird der modifizierte Kernel kompiliert und installiert. Für Administratoren, die auf Kernel-Sicherheit wert legen, bietet dies eine Möglichkeit, eine auf ihre Bedürfnisse zugeschnittene Ablaufumgebung für Container zu erstellen. Gleichzeitig entsteht allerdings eine zusätzliche Ebene von Abhängigkeiten, die verwaltet werden muss.

Sicherung des Docker Daemon

Auf der Oberseite der Host-Schicht sitzt der Docker Daemon/API, durch den der Zugriff auf die Container und/oder Hosts durch einen Angreifer erfolgen kann. Sichere Kommunikation und Autorisierung in dieser Schicht reduziert die potentielle Angriffsfläche.

Docker und Sicherheit: Wie passt das zusammen?

Ein sinnvoller Ausgangspunkt zur Absicherung eines Docker-Setups besteht darin, die Nutzung von Registries sicherer zu gestalten. Standardmäßig ist die Kommunikation durch HTTPS gesichert, es sei denn der Docker Daemon wurde mit dem Parameter „--insecure-registry“ gestartet. Ein einfacher Härtungsschritt des Systems ist somit darauf zu achten, dass dieser Schalter nicht gesetzt ist. Durch den zusätzlichen Einsatz von „--registry-mirror https://...“ sind Anfragen auf URLs mit vorangestelltem https:// eingeschränkt.

Mittlerweile dürfte bekannt sein, dass Nutzer mit Zugriff auf das REST API einer Docker-Instanz Root-Rechte erlangen können. Docker erlaubt es, „--privileged“ Container als Root zu starten, die im Rahmen ihrer Linux Capabilities nicht eingeschränkt sind und somit weitreichende Rechte besitzen. Weiterhin lassen sich bestimmte Namespace-Aspekte abstellen, z.B. das Netzwerk mit dem des Hosts (--net=host) oder den Prozessraum mit anderen Container zu teilen (--pid=...). Während solche Einstellungen beim Testen, Debuggen oder für Systemwerkzeuge sinnvoll sein können, führen sie bei Applikationen dazu, dass das Sicherheitsniveau herabgesetzt wird. Ein Kernelement bei der Härtung des Dämons stellt das Docker-API dar: Solange es kein Berechtigungsmodell besitzt, sollte zumindest der Zugriff auf das API eingeschränkt werden.

Bei Verwendung der Socket-Option (/var/run/docker.sock) sollten die Zugriffsrechte (für die Root und Docker-Gruppe beschreibbar) überprüft werden. Vor allem ist darauf zu achten, dass die Docker-Gruppe nicht ungewollt Benutzer enthält, die über diesen Zugriffsweg quasi-root Rechte erlangen. Idealerweise sollten keine Nutzer in der Docker Gruppe oder der Socket-Zugang vollständig deaktiviert sein. Darüber hinaus ist es sinnvoll, wenn der Zugang auf das API über das Netz nur über TLS erfolgt. Hierbei werden clientseitig TLS-Zertifikate und Schlüssel an Server und Nutzer verteilt, um einen Zugriff zu gewähren. Die TLS-Schlüssel selber sollten durch die Beschränkung des Dateizugriffs gesichert werden.

Beim TLS-Setup ist es sinnvoll, nicht nur eine TLS-Verschlüsselung durch das Setzen des „--tls"-Schalters, sondern die clientseitige Authentifizierung durch die Aktivierung der „--tlsverify“-Parameters zu erzwingen. Zertifikate und Schlüssel müssen dem Docker Daemon bekannt sein und z.B. unter /etc/default/docker abgelegt werden. Außerdem sollte der Service immer unter einer dedizierten IP-Adresse laufen und sich nicht auf alle Interfaces (0.0.0.0) binden:

DOCKER_OPTS= "$DOCKER_OPTS --tlsverify --tlscacert=/etc/docker-TLS/cacert.pem --tlscert=/etc/docker-TLS/certs/Server-cert.pem --tlskey=/etc/docker-tls/private/server-key.pem -H=192.168.0.10:2376

Eine zusätzliche Möglichkeit für eine weitere Isolationsschicht stellen SELinux oder AppAmor-fähige Systeme zur Verfügung. Installationen, die auf RHEL7 oder Fedora >21 basieren, haben SELinux als Standard aktiviert und der Docker Daemon läuft „confined“ in einer speziellen SELinux-Domain. Bei Debian-basierten Systemen lässt sich ein AppAmor-Profil aktivieren, das einen ähnlichen Isolationsmechanismus zur Verfügung stellt.

Ein Beispiel: Bei Systemen mit aktiviertem SELinux kann geprüft werden, ob Docker in einer abgeschotteten Domain läuft. Hierzu kann die „-Z“-Option bei Basiskommandos wie netstat und ps genutzt werden:

# ps -efZ | grep docker system_u:system_r:docker_t:SystemLow root 1873 1 2 7.21? 00.00.00 /usr/bin/docker -d --selinux-enabled

Die erste Spalte zeigt den Sicherheitskontext. Der Teil docker_t ist ein Domain-Typ mit beschränkten Rechten. Wichtig ist beim Docker Daemon der „--selinux-enabled“-Parameter.

Sicherung von Images und Image-Erstellung

Host und Docker Daemon sollten jetzt gesichert sein und nur erlaubten Clients einen Zugang zu diesen Ressourcen ermöglichen. Die gleiche Sorgfalt ist beim Herunterladen und Ausführen von Images aus unsicheren und/oder unbekannten Quellen anzuwenden. Nur eine verifizierbare Vertrauenskette während der Erstellung des Images stellt sicher, dass der laufende Container mit Hilfe eines vertrauenswürdigen Images gestartet wurde.

Jede Erstellung eines Docker Containers beginnt mit einem Image – diese Image wird von einem öffentlichen Repository des Docker Hub heruntergeladen. Hier sollten ebenfalls Härtungsmechanismen eingesetzt werden, da dies eine komplette „Userland“-Installation mit Bibliotheken und Binaries darstellt. Die Maßnahmen werden direkt durch die Anzahl der installierten Pakete beeinflusst, nach dem Motto: je weniger, desto besser. Das geht soweit, dass z.B. aktuelle Images von Fedora kein /bin/ip mehr enthalten. Sichere Repositories wie Ubuntu oder CentOS enthalten in ihrer Dokumentation Informationen über den Umgang mit Updates von Basis-Images, z.B. wie rollierende Updates durchgeführt oder wie Patches in Image Tags umgesetzt werden [tags].

Die Webseite von Docker stellt Best Practices zur Erstellung von Images bereit [docker-images]. Diese zeigen, wie man Dockerfiles schreibt, die zu stabileren und sicheren Images führen. Ein weiterer Ansatz ist es, sich die Dockerfiles von vertrauenswürdigen Repositories anzuschauen.

Letztendlich ist eine Grundvoraussetzung, dass man einer dritten Partei vertraut, dass diese ein gültiges Basis-Image

ohne Schwachstellen anbietet. Für Unternehmen, die sich nicht auf solche Images verlassen können und wollen, besteht die Möglichkeit, Container Images von Grund auf individuell zu erstellen. Hierfür sind Tools wie debootstrap oder appliance-creator geeignet.

Ein Mittelweg zwischen der Nutzung von Fremd-Images und der Erzeugung eigener Images ist seit Docker 1.8 der „content trust“. Durch dieses Feature wird der Zugriff des Docker Clients auf vom Herausgeber bei Veröffentlichung signierte Image-Tags eingeschränkt. Diese Funktion wird mit der folgenden Umgebungsvariablen aktiviert:

~# export DOCKER_CONTENT_TRUST = 1

oder direkt vor jeden Docker Client Befehl gestellt:

~# env DOCKER_CONTENT_TRUST=1 docker pull (...)

Sobald der „content trust“ aktiviert wurde, ist das Herunterladen eines Images nur mit einem signierten Image Tag möglich. Andernfalls bricht die Ausführung mit der folgenden Fehlermeldung ab:

~# env DOCKER_CONTENT_TRUST=1 docker pull dewiring/trustit:latest no trust data available Nachdem der Herausgeber das Image Tag korrekt signiert hat, kann es erfolgreich heruntergeladen werden, s. Beispiel in Kasten 1.

Signiert wird durch Offline- und Tagging-Keys, die beim ersten Pushen eines Image in eine Registry erstellt werden. Der Offline-Key ist der Master-Key für den Herausgeber und für jedes Repository werden individuelle Tagging-Keys erstellt. Alle Keys werden im Client

gespeichert und nur der Zeitstempel und die Signatur werden als Metadaten mit dem Image Tag in der Docker Registry abgelegt. Mehr zu diesem Thema unter [content trust] im Linkbereich am Ende des Artikels.

Absichern von Containern während der Laufzeit

Nach Härtung des Hosts und der Docker Images folgt nun die Runtime-Phase der Container. In dieser können viele Sicherheitseinstellungen individuell angepasst werden. Es ist ratsam Container unter einer dedizierten User-ID und nicht als Benutzer Root laufen zu lassen solange „User Namespaces“ noch nicht allgemein eingesetzt werden können. Diese Funktion muss explizit mit dem Parameter “--user=“ gesetzt werden.

Weitere Parameter wie „--privileged“, “--device“, „--net“, „--pid“, „--uts“ lassen eine Ausweitung der Rechte zu, die sich eventuell auf den Host auswirken können. Diese Parameter sind eher für Systemdienste und weniger für Applikationen relevant. Deswegen sollten Applikationen, z.B. solche, die unsicheren Traffic von öffentlichen Netzwerken erlauben, nicht mit erweiterten Ressourcen oder – gravierender – mit erweiterten Rechten ausgeführt werden.

Die Docker Engine deaktiviert viele Linux-Capabilities, wenn Container gestartet werden, z.B. die deaktivierte CAP_NET_ADMIN-Funktion hält Prozesse innerhalb des Containers davon ab, die Netzwerkschnittstelle zu verändern. Zwei Funktionen, CAP_SETUID und CAP_SETGID, sind sehr interessant, weil sie unterbinden, dass der Containerprozess sich eine andere User- oder Gruppen-ID aneignet – ein geeigneter Einstiegspunkt für Attacken auf ein System. Deshalb verbessert ein zusätzliches „--cap-drop SETUID --cap-

Kasten 1 – Korrekte Image-Signatur bei Docker Content Trust

~# env DOCKER_CONTENT_TRUST=1 docker pull dewiring/trustit:latest Pull (1 of 1): dewiring/trustit:latest@sha256:c58ee9f9d1b1a0b59471cac2c089ac995dd559949ee088533fc6f4a0dcd2719f sha256:c58ee9f9d1b1a0b59471cac2c089ac995dd559949ee088533fc6f4a0dcd2719f: Pulling from dewiring/trustit 2c49f83e0b13: Already exists 4a5e6db8c069: Already exists 88ab9df21bce: Already exists 2c900b53c032: Already exists 8d86df29cb44: Already exists Digest: sha256:c58ee9f9d1b1a0b59471cac2c089ac995dd559949ee088533fc6f4a0dcd2719f Status: Downloaded newer image for dewiring/trustit@sha256:c58ee9f9d1b1a0b59471cac2c089ac995dd559949ee088533fc6f4a0dcd2719f Tagging dewiring/trustit@sha256:c58ee9f9d1b1a0b59471cac2c089ac995dd559949ee088533fc6f4a0dcd2719f as dewiring/trustit:latest

drop SETGID“ die Sicherheit eines Anwendungssystems. Die Deaktivierung von Funktionen sollte gründlich getestet werden, um sicherzustellen, dass die Anwendung fehlerfrei läuft. Wenn Einschränkungen von Funktionen ausgerollt werden, lässt sich ein „capsh –print“ innerhalb eines Containers ausführen. Hierdurch lässt sich überprüfen, welche Capabilities aktiviert sind (hier 14):

~# docker run -ti \ de-wiring/debian:jessie /bin/bash /# capsh --print Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eip (...) Mit dem Schalter --privileged dagegen sind es 37:

~# docker run -ti --privileged \ de-wiring/debian:jessie /bin/bash /# capsh --print Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend+eip (...)

Docker nutzt intensiv Linux Control Groups (cgroups), um Containerprozesse in Bezug auf ihre Ressourcennutzung einzuschränken. Dies ist z.B. bei Abwehr von Denial of Service Attacken sinnvoll, damit einzelne Container nicht das Gesamtsystem zum erliegen bringen können. Eine Reihe von Parametern beim Befehl „docker run“ erlauben es, sowohl CPU als auch Speicher-Ressourcen je Container einzuschränken. Eine Voraussetzung für eine sinnvolle Einteilung von Ressourcen ist die Identifikation passender Limits, z.B. durch das Durchführen von Last-

und Performance-Tests vor dem Deployment, s. Kasten 2.

Weiteres Potenzial für eine Isolierung liegt im “--security-opt“ Parameter. Es erlaubt, den Container mit zusätzlichen Sicherheitsoptionen in Bezug auf SELinux oder AppArmor auszustatten. Auf diesem Weg können Administratoren Container stärker voneinander abschotten, z.B. in dem Container mit maßgeschneiderten SELinux Domain-Types oder unter AppAmor-Profilen laufen. Einige SELinux-Beipiele findet man unter [dewiringselinux], allerdings müssen diese Beispiele für die Zielapplikation angepasst werden.

Überprüfung der Härtung

Einige der beschriebenen Härtungsschritte sollten durch Konfigurationsmanagement-Tools ausgerollt werden, Danach stellt sich die Frage, wie – im Falle einer Verletzung von Härtungsmaßnahmen – nachteilige Änderungen aufgespürt werden können.

Abhilfe kann die kontinuierliche Überwachung von Logfiles schaffen, welche Härtungsmaßnahmen automatisiert überprüfen. Zusammen mit dem „Center for Internet Security“ [cissecbench] führte Docker den CIS 1.6 Docker Security Benchmark ein. Dieser umfasst Aspekte rund um die im Artikel dargestellten Themen, außerdem sind Werkzeug-Implementierungen in unterschiedlichen Formaten verfügbar:

• Der docker-bench-security [dockerbench] ist eine Shell-basierte Lösung

• Batten [batten] ist in go implementiert • Für Fans der testgetriebenen Infrastruktur existiert eine

Serverspec-Implementierung [dewiring1]

Dadurch, dass die Sicherheitsaspekte jeweils von unterschiedlichen Betriebssystemen und Umgebungs-variablen abhängig sind (z.B. SELinux bei RHEL-basierten Systemen) muss jede Implementierung individuell angepasst werden.

Das folgende Codebeispiel zeigt einen Ausschnitt aus einem Serverspec-basierten Code. Dieses dient dazu, Konfigurationsoptionen zu überprüfen.

Kasten 2 – Auswahl einiger einstellbarer CPU- und Speicherbeschränkungen

# docker help run | grep -E 'cpu|mem'

-c, --cpu-shares=0 CPU shares (relative weight) --cpu-period Limit CPU CFS (Completely Fair Scheduler) period --cpu-quota=0 Limit the CPU CFS quota --cpuset-cpus= CPUs in which to allow execution (0-3, 0,1) --cpuset-mems= MEMs in which to allow execution (0-3, 0,1) -m, --memory= Memory limit --memory-swap= Total memory (memory + swap), '-1' to disable swap

describe 'Restrict network traffic' do describe process 'docker' do its(:args) { should match /--icc=false/ } end end describe 'Insecure Registries' do describe process 'docker' do its(:args) { should_not match /--insecure-registry/ } end end describe 'Local Registry mirror' do describe process 'docker' do its(:args) { should match /--registry-mirror=https:.*/ } end end

Fazit

Welche Punkte sind wichtig? Als erstes sollte die Absicherung einer Docker-Umgebung nach dem „Zwiebelschalen-Prinzip“ erfolgen: es ist sinnvoll, Härtungsmechanismen auf unterschiedlichen Schichten einer Infrastruktur zu implementieren. Docker bietet eine steigende Zahl an sicherheitsorientierten Funktionen, um proaktiv die Sicherheit von Container-Umgebungen zu erhöhen.

Dabei hat der Nutzer die Wahl, das gewünschte Niveau der benötigten Sicherheit selber festzulegen. Die Anzahl und Vielfalt der Sicherheitsfunktionen sind Fluch und Segen zugleich, da funktionale Aspekte, die sich um das Thema Sicherheit drehen, schnell die Komplexität erhöhen - und dies wiederum beeinflusst die Benutzerfreund-lichkeit.

Die Härtung eines Systems ist keine einmalig durchzuführende Aufgabe, sondern bedarf der kontinuierlichen Pflege.

Sicherheitschecks helfen dabei, des Status eines Systems regelmäßig zu überwachen. Der CIS Docker Security Benchmark ist hierfür ein sinnvoller Anfang. Dort sind – um zu einem schnellen Ergebnis zu kommen – bereits einige Implementierungen von System-Checks verfügbar.

Links

• [Lynis] – https://github.com/CISOfy/Lynis

• [hardening.io] – http://www.hardening.io/

• [tags] – https://docs.docker.com/userguide/dockerimages/#setting-tags-on-an-image

• [cissecbench] – https://benchmarks.cisecurity.org/downloads/show-single/?file=docker16.100

• [dockerbench] – https://github.com/docker/docker-bench-security

• [dockersectalk] – http://de.slideshare.net/JenAndre/docker-security-talk

• [grsecurity] – http://www.grsecurity.net/

• [dewiringselinux] – https://github.com/de-wiring/tests-docker-hardening

• [content trust] – https://docs.docker.com/security/trust/content_trust/

• [docker_images] - https://docs.docker.com/engine/articles/dockerfile_best-practices/

Ihre Ansprechpartner bei Cassini:

Andreas Schmidt Management Consultant E-Mail: andreas.schmidt@cassini.de

Cassini Consulting GmbH Bennigsen-Platz 1 40474 Düsseldorf

www.cassini.de T: +49 211 - 65 85 41 33 F: +49 211 - 65 85 41 34

Dustin Huptas Management Consultant E-Mail: dustin.huptas@cassini.de

Cassini Consulting Nord GmbH Oberwallstraße 24 10117 Berlin

www.cassini.de T: +49 30 – 50 10 14 0 F: +49 30 – 50 10 14 14

© 2016 Cassini Consulting GmbH