© chaiyapruek youprasert, 123RF

Docker-Container sind eine bequeme und leicht verfügbare Möglichkeit, um beinahe jeden Dienst zu betreiben. Damit das Thema Sicherheit nicht auf der Strecke bleibt, sollten Admins einige Dinge beachten.

Docker und kein Ende: Die leichtfüßigen VM-Alternativen erfreuen sich bei Entwicklern wie bei Admins größter Beliebtheit. Da landet ganz automatisch auch das Thema Sicherheit auf dem Tisch: Immerhin ist die Trennung zwischen Container und Host deutlich durchlässiger als jene zwischen einer echten VM und ihrem Hostsystem. Zudem haben Container unmittelbaren Zugriff auf Verzeichnisse wie »/proc«, »/dev« oder auch »/sys«, sodass das Gefahrenpotenzial steigt.

Die gute Nachricht ist: Es ist problemlos möglich, Docker-Container sicher zu betreiben, und zwar auch in jenen Setups, in denen mehrere Docker-Container verschiedener Kunden auf einem System laufen. Die Grundregeln, die der Admin in diesen Fällen beachten sollte, erklärt der folgende Artikel.

Der Docker-Daemon

Container sind keine virtuellen Maschinen, die ohne ein vollständig emuliertes System daherkommen – das ist deutlich zu kurz gesprungen. Denn unter der Haube funktionieren Container fundamental anders als virtuelle Maschinen. Anstelle eines Hypervisors setzen Container unter Linux auf die verschiedenen Namespace-Funktionen, die Teil des Linux-Kernels selbst sind.

Der Start eines Containers bedeutet letztlich nichts anderes, als ein Image in das Dateisystem des Hosts auszurollen und mehrere Namespaces zu schaffen. Dafür zeichnet bei Docker der Daemon verantwortlich, der Teil der Docker-Umgebung ist: »dockerd«. Da ist es nur logisch, dass dieser Dienst in vielen Bedrohungsszenarien als erstes Einfallstor gilt.

In der Tat steht es um die Sicherheit des Docker-Daemons zumindest in der Standardkonfiguration nicht zum Besten. Der Daemon kommuniziert etwa mit dem »docker«-Kommandozeilenwerkzeug mittels eines Unix-Sockets (Abbildung 1). Bei Bedarf lässt sich zudem ein HTTP-Socket aktivieren, sodass der Zugriff auch über das Netzwerk möglich wird.

Abbildung 1: Ab Werk lauscht der Docker-Daemon auf einem Unix-Socket, wer den HTTP-Socket dazuschaltet, sollte unbedingt Clientzertifikate nutzen.

Das Problem: Ab Werk ist der HTTP-Zugriff nicht gesichert. Auf Centos-Systemen springt hier zwar »firewalld« in die Bresche und verhindert ungewollten Zugriff. Ähnlich verhält es sich auf Ubuntu-Systemen, falls die Ubuntu-Firewall aktiv ist. Wer aber auch auf der Ebene des Docker-Daemons selbst Sicherheit möchte, greift zu einem auf TLS aufbauenden System mit Clientzertifikaten.

Clientzertifikate einrichten

Die Docker-Konfiguration für dieses Setup ist gar nicht kompliziert: In der Konfigurationsdatei des Docker-Daemons aktiviert der Admin die Parameter » tlsverify«, »tlscacert«, »tlscert« sowie »tlskey« [1] jeweils mit den entsprechenden Dateien als Parameter. In der Clientkonfiguration im Ordner »~/.docker« hinterlegt er anschließend jene Dateien, sorgt mit den Schlüsselwörtern »tls«, »tlscert« und »tlskey« sowie »tlscacert« dafür, dass Docker sie auch findet, und setzt die Umgebungsvariable »DOCKER_TLS_VERIFY« auf »1«. Ruft er danach den Befehl »docker« auf der Kommandozeile auf, nutzt dieser die Zertifikate für die Anmeldung beim Server automatisch.

Deutlich komplexer als das Setup der Docker-Konfiguration ist allerdings der Umstand, dass man für dieses Prinzip entweder entsprechende Zertifikate kaufen muss oder in die Verlegenheit kommt, eine passende CA selbst zu betreiben. Werkzeuge wie Tiny CA [2] helfen dabei, diese Aufgabe etwas erträglicher zu gestalten (Abbildung 2). Wer intrinsische Sicherheit auf Ebene des Docker-Daemons braucht, kommt um diese Arbeit leider nicht herum.

Abbildung 2: Ein Werkzeug wie Tiny CA erleichtert das Verwalten einer eigenen lokalen SSL-CA. Tiny kann auch mit bereits existierenden CA-Zertifikaten umgehen.

System von Privilegien

Unter Admins ist es eine Binsenweisheit, dass die Arbeit mit Rechten des Systemadministrators »root« im Alltag auf das absolute Mindestmaß reduziert sein sollte. Im Kontext von Docker-Containern ist das Thema Systemnutzer nicht minder relevant: Eben weil ein Container keine vollständige VM ist, existiert keine komplette Trennung zwischen der Benutzerverwaltung innerhalb des Containers und jener außerhalb. Das bedeutet auch: Startet ein Admin einen Container mit den Rechten des Systemadministrators »root«, hat dieser eine ganze Reihe weitreichender Befugnisse.

Damit kein falscher Eindruck entsteht: Docker selbst kommt ab Werk gleich mit mehreren Maßnahmen, um daraus kein Problem werden zu lassen. Beim Start eines Containers legt es im Hintergrund mehrere Namespaces auf Kernel-Ebene an, namentlich einen für die Netzwerkverbindungen des Containers sowie einen für die Prozesse innerhalb des Containers.

Applikationen im Container haben somit keine Möglichkeit, an Informationen über die Prozesse außerhalb ihres Containers zu gelangen – vorausgesetzt natürlich, dass in der Namespace-Implementierung des Linux-Kernels keine Sicherheitslücke klafft. Control Groups legt Docker für neue Container ebenfalls an. Diese limitieren den Zugriff auf Ressourcen durch den Container, sodass etwa ein einzelner Container nicht die ganze auf dem Host verfügbare CPU-Power in Anspruch nehmen kann.

Weil der Container aber auch Zugriff auf zentrale Verzeichnisse wie »/sys« benötigt, haben die Docker-Entwickler obendrein das Konzept der Linux Capabilities in Docker übernommen. Ein Docker-Container selbst hat – es sei denn, der Admin definiert es anders – lediglich die Rechte einer unprivilegierten Applikation. Hinzu kommt eine ganze Reihe zusätzlicher Capabilities wie »CHROOT«, um das Ausführen der Chroot-Funktion in einem Container zu erlauben, oder »SYS_RAWIO«, um direkten Zugriff auf Storage-Geräte zu bekommen.

Die gute Nachricht: Mit den »–cap-add«- und »–cap-drop«-Optionen für »docker« ist es dem Admin möglich, jedem Container nur genau jene Privilegien einzuräumen, die dieser tatsächlich benötigt. Muss ein Container zum Beispiel einen privilegierten Port nutzen – also einen unterhalb der Grenze von Port 1024 – aktiviert der Admin für den Container einfach das »NET_BIND_SERVICE«-Capability-Flag – fertig.

Ein anderer Ansatz, der sich in diversen Dokumenten zum Thema wiederfindet, betrifft den »–privileged«-Schalter. In Sachen Capabilities ist dieser die umfassende Keule: Startet ein Admin einen Container im Privileged-Modus, darf dieser praktisch alles, was Root auf dem Hostsystem darf. Anders als bei der erwähnten Binsenweisheit im Hinblick auf die Arbeit als Root folgen viele Nutzer tatsächlich dieser Empfehlung – sie statten den Container also mit umfassenden Berechtigungen aus, obwohl der sie vermutlich gar nicht braucht.

Eine der wichtigsten Empfehlungen im Hinblick auf den sicheren Docker-Betrieb ist es deshalb, Container nur in absoluten Ausnahmefällen im privilegierten Modus zu starten und immer sorgsam zu prüfen, ob das unbedingt nötig ist. Der potenzielle Schaden, der durch einen Amok laufenden Container mit »privileged«-Rechten entstehen kann, reicht bis zum Absturz des Hosts.

Eigene User-Namespaces

Seit Version 1.10 beherrscht Docker übrigens auch die Möglichkeit, eigene User-Namespaces für Container zu verwenden. Die Nutzerverwaltung innerhalb des Containers ist von der außerhalb dann vollständig getrennt. Dazu muss der Docker-Daemon mit dem Parameter »–userns-remap« gestartet sein. Sobald das der Fall ist, gibt es innerhalb des Containers keinen klassischen Benutzer Root mehr: Stattdessen läuft der Container in einem User-Namespace, der den Nutzer Root des Hostsystems auf eine beliebige UID mappt, während der im Container laufende Dienst noch immer glaubt, Rootrechte zu haben (Abbildung 3).

Abbildung 3: Sind User-Namespaces in Docker aktiviert, mappt Docker die UID 0 des Hosts auf eine beliebige ID um, die im Container als UID 0 erscheint, jedoch keine Rootrechte auf dem Hauptsystem hat.

Seccomp

Neben den Sicherheitsmaßnahmen, die in Docker selbst implementiert sind, haben Admins auch die Möglichkeit, das Thema Docker-Sicherheit über externe Werkzeuge anzugehen. Ein prominentes Beispiel dafür ist die Seccomp-Funktion, die Teil des Linux-Kernels ist und ursprünglich für Google Chrome entwickelt wurde. Das Prinzip ist simpel: Seccomp beschränkt die erlaubten Systemaufrufe (Syscalls) auf das absolut notwendige Minimum.

Zur Erinnerung: Syscalls sind auf jedem Posix-kompatiblen Betriebssystem im Kernel verankerte Funktionen, die sich von externen Programmen aufrufen lassen. Die bekanntesten Systemaufrufe in Linux sind die für die Interaktion mit Dateien in Dateisystemen, namentlich »open()«, » read()« und »write()«. Es gibt aber auch Systemaufrufe, die tief in das laufende System eingreifen, beispielsweise »clock_settime()«, mit dem sich die Uhrzeit des Zielsystems verändern lässt; »mount()« etwa ist ebenfalls ein Systemaufruf.

Seccomp basiert auf dem Prinzip von Profilen: In einem solchen Profil legt der Administrator fest, auf welche Systemaufrufe ein Programm Zugriff hat. Das Zielprogramm muss Seccomp unterstützen, denn es muss das Profil, mit dem es assoziiert sein möchte, selbst auswählen und durch den »seccomp()«-Syscall setzen. Versucht ein Programm, das durch ein Seccomp-Profil eingeschränkt ist, einen im Profil nicht ausdrücklich erlaubten Syscall auszuführen, schickt der Kernel des Hostbetriebssystems ihm kurzerhand das »SIGKILL«-Signal und befördert es so ins Nirwana.

De facto agiert die Seccomp-Funktionalität also als Erweiterung des schon beschriebenen Linux-Capability-Systems: Nicht alle Operationen, die man als Admin einem Docker-Container verbieten möchte, lassen sich über Capabilities abdecken – hier springt Seccomp in die Bresche. Noch eine gute Nachricht: Seit Version 1.10 beherrscht Docker das Setzen von Seccomp-Profilen auf Basis von einzelnen Containern. Das Standardprofil ist in [3] ausgiebig erklärt, dort steht auch, welche Funktionen dieses Standardprofil blockiert.

Gibt der Admin nicht ausdrücklich den Parameter »–security-opt seccomp= unconfined« mit auf den Weg, wenn er einen Container startet, kommt eben jenes Seccomp-Profil auch zum Einsatz. Benötigt der Admin im Container einen Syscall, den das Standard-Seccomp-Profil blockiert, legt er sich alternativ ein eigenes Seccomp-Profil für diesen Container an und referenziert es beim Programmstart mit »–security-opt seccomp=Pfad zum Profil«, wobei das Profil im Json-Format vorliegen muss. Dringend abzuraten ist davon, Seccomp für einen Container vollständig zu deaktivieren.

Mandatory Access Control

Im Docker-Sicherheitskontext darf auch das Thema Mandatory Access Control (MAC) nicht unerwähnt bleiben – auch wenn es bei vielen Admins in schlechtem Ruf steht. Auf Systemen ohne die entsprechende Technik gilt, dass einzig das klassische Unix-Rechtekonzept darüber entscheidet, wer Zugriff auf Dateien oder Geräte bekommt und welche Systemaufrufe er beim Zugriff auf Ressourcen verwenden darf.

MAC verkehrt dieses Prinzip ins Gegenteil, das heißt, es gilt das Prinzip, dass der Zugriff seitens des Systems nur auf jene Ressourcen ermöglicht wird, die das jeweilige Programm tatsächlich benötigt. Die prominentesten Implementationen von MAC für Linux sind SE Linux und App Armor.

Beide Lösungen sind aber nicht sonderlich beliebt: In vielen Anleitungen und Howtos findet sich gleich am Anfang irgendwo die Anweisung, SE Linux in den Permissive Mode zu schalten oder App Armor am besten gleich ganz zu deaktivieren. Denn viele empfinden die Arbeit mit den Werkzeugen als nervig: Die MAC kann bewirken, dass Programme aus anfangs schwer nachvollziehbaren Gründen nicht auf Dateien zugreifen oder bestimmte Funktionen nicht ausführen dürfen. Bei App Armor unter Ubuntu zum Beispiel hilft dann nur ein Blick auf die Ausgaben von »dmesg«, um herauszufinden, dass App Armor den Zugriff auf eine Datei verhindert hat.

Trotzdem ist es nicht sinnvoll, SE Linux oder App Armor von vornherein ersatzlos aus dem Setup zu streichen. Unter [4] ist mittlerweile sogar eine Website zu finden, die keck festhält: Jedes Mal, wenn ein Admin auf seinen Systemen SE Linux deaktiviert, weint Dan Walsh, der als Kopf hinter SE Linux gilt. Etwas lapidar lautet die Aufforderung, sich stattdessen mit der Benutzung von SE Linux zu beschäftigen und zu verstehen, wie es sich sinnvoll nutzen lässt.

Auf Systemen, auf denen Docker-Container laufen, ist das tatsächlich eine sehr gute Idee – zumal Docker sich viel Mühe damit gegeben hat, die SE-Linux-Nutzung (und auch jene von App Armor auf Ubuntu-Systemen) so angenehm wie möglich zu gestalten. Wer auf einem Host also Docker-Container betreibt, sollte dort SE Linux auf keinen Fall komplett abschalten.

Falls SE Linux oder App Armor doch einmal zu viel blockieren, empfiehlt es sich außerdem, die entsprechenden Profile zu studieren und anzupassen, statt dem kompletten Dienst den Garaus zu machen. Gerade weil die Trennung zwischen Host und Container in Docker schwächer ist als bei herkömmlichen VMs, ist Mandatory Access Control für diese Setups eine große Hilfe.

Noch mehr Sicherheit mit Docker EE

Wer Docker im großen Umfang einsetzt, spielt vielleicht mit dem Gedanken, die Enterprise Edition von Docker zu kaufen (Abbildung 4). Zumindest aus der Sicherheits-Perspektive ist das keine schlechte Idee, denn die Enterprise Edition kommt mit diversen zusätzlichen Funktionen daher, die in der Community Edition fehlen. Das prominenteste Beispiel dafür dürfte das RBAC-System sein, das in der Enterprise Edition zum Lieferumfang gehört.

Abbildung 4: Die Enterprise Edition von Docker bringt eine komplette Benutzerverwaltung mit – von den Systemen komplett entkoppelt.

Damit ist es möglich, Docker an ein bestehendes Nutzerverzeichnis anzubinden, etwa an LDAP. Auf Basis von festgelegten Rollen lässt sich danach feingranular festlegen, wer was in Docker tun darf. Anders als bei der Community Edition ist in diesem Ansatz die Benutzerverwaltung von Docker komplett von der des Systems entkoppelt. Garniert mit den grafischen Verwaltungswerkzeugen, die die Enterprise Edition bietet und die die Konfiguration verschiedener Sicherheitsfunktionen ebenso erlaubt, ergibt sich hier also echter Mehrwert.

Im Innern der Container

Der letzte Teil des Artikels widmet sich dem Innenleben der betriebenen Container. Die bis hierhin diskutierten Aspekte drehen sich ja ausschließlich um die Frage, wie Admins das System abhärten, auf denen die Docker-Container laufen. Wer allerdings die Innenperspektive vergisst, ist weiterhin verwundbar. Selbst wenn ein Container ohne besondere Rechte oder Privilegien existiert, kann es dem Admin kaum egal sein, wenn in diesem etwa Malware läuft. Wer sein Setup auf Docker-Basis konstruiert, muss sich also auch um den Inhalt seiner Container kümmern.

Der Docker Hub ist bekanntlich die größte Onlinebörse für Container mit Docker-Hintergrund, die aktuell besteht. Wer im Docker Hub einen Container für die Community zur Verfügung stellen möchte, hat es nicht schwer: Erst steht die Registrierung auf dem Programm, danach sind noch ein paar Details technischer Art zu erledigen und dann kann es bereits losgehen. Noch leichter ist es, will ein Admin einen per Docker Hub angebotenen Container selbst nutzen: Ein simples »docker pull« gefolgt von einem »docker run« reicht aus.

Das Linux-Magazin ist bereits mehrere Male auf die inhärenten Gefahren zu sprechen gekommen, die dieses System mit sich bringt. Wichtigster Faktor aus Admin-Sicht ist, dass viele Docker-Container Blackboxes sind. Zwar kann ein Image-Anbieter das »Dockerfile«, auf dem der Container basiert, ebenfalls auf Github hochladen. Docker Hub selbst kann aber nicht sicherstellen, dass das hochgeladene Image tatsächlich auch aus einem Aufruf des ebenfalls hochgeladenen »Dockerfile« stammt.

Die Situation ist in weiten Teilen identisch mit einem Streit, den Debian und Ubuntu seit Jahren miteinander austragen: Während beim Debian-Projekt der Upload durch den Maintainer eines Pakets auch Binärpakete enthalten darf, also Pakete, die der Entwickler bei sich lokal gebaut hat, ist genau dies bei Ubuntu verpönt. Auch Launchpad mit seinen PPA-Verzeichnissen akzeptiert nur Source-Pakete und baut die passenden Binärpakete selbst.

Docker folgt eher dem Debian-Ansatz, was im schlimmsten Falle fatale Auswirkungen für die Nutzer nach sich ziehen kann. So oder so: Greift ein Admin im Vertrauen auf einen fertigen Container im Hub zurück, muss er letztlich darauf vertrauen, dass der Image-Autor seine Arbeit zuverlässig und reproduzierbar erledigt hat – oder er muss den Container-Inhalt auf eigene Faust untersuchen.

Kontrolle ist besser

Das ist aber kein besonders realistisches Szenario, denn wer viele Stunden investiert, um die Inhalte eines Containers zu analysieren, kann ihn auch gleich selber bauen. Dabei empfiehlt es sich, auf ein paar Best Practices zu setzen.

Die erste Regel etwa sollte sein, dass man seinen eigenen Container auf Basis eines offiziellen Distributoren-Image erstellt. Treppenwitz: Auch jene stehen freilich über den Docker Hub zur Verfügung, so dass man auch hier dem Autor vertrauen muss. Weil Debian, Ubuntu, Centos und viele andere Linuxe ihre offiziellen Docker-Images aber selber bauen, ist das in Ordnung – zumal sich die entsprechenden Dockerfiles ebenfalls im Docker Hub finden.

Letztlich unterscheidet sich die Situation ja nicht signifikant von einem installierten System – auch hier vertraut der Admin dem Distributor. Dass es sich zudem meist lohnt, auf die offiziellen Distributionscontainer zu setzen, zeigt schon deren Größe: Das Ubuntu-Basis-Abbild etwa liegt deutlich unter 100 MByte; selbstgestrickte Abbilder sind in aller Regel viel größer, weil sie zum Beispiel mehr Pakete enthalten. Unnütze Pakete im Container sind aber selbst schon ein relevanter Aspekt in Sachen Sicherheit.

Vollautomatisch

Wer seine Docker-Container selbst entwickelt, muss auch deren spätere Wartbarkeit im Hinterkopf behalten: Erscheint für Bibliotheken oder Programme, die im Container existieren, ein Sicherheitsupdate, möchte der Admin aus dem Stegreif in der Lage sein, den relevanten Container per Dockerfile neu und gleich mit dem aktualisierten Paket zu bauen. Das setzt voraus, dass er für seine eigenen Container eine komplette Continuous-Integration-Umgebung betreibt, etwa auf Basis von Gitlab.

Ein ausführlicher Artikel dazu, wie sich die bei Gitlab ab Werk vorhandene Funktionalität nutzen lässt, findet sich ebenfalls in diesem Heft.

Wer diese Art des Container-Workflows für das eigene Setup umsetzt, hat noch eine weitere Option: Das Content-Trust-Feature von Docker erlaubt es, ausschließlich solche Images aus einer anderen Registry herunterzuladen, die digital signiert sind. Welcher Schlüssel dabei genutzt werden darf, entscheidet freilich der Admin.

Das Prinzip funktioniert so: Das Registry-Protokoll von Docker sieht ähnlich wie die gängigen Versionskontrollsysteme die Möglichkeit vor, einzelne Images mit Tags zu versehen (Abbildung 5). Die Signierfunktion der Docker-Registry basiert auf eben diesen Tags. Per »docker«-Befehl legt der Bastler einmal die entsprechenden Schlüssel an und wählt dann beim Taggen von Images auf Basis des Einzelfalles aus, ob er das jeweilige Tag digital signieren möchte oder nicht.

Abbildung 5: Das Prinzip der Signed Tags ermöglicht es, die Herkunft eines Abbilds zu verifizieren.

Nutzt er die Signierfunktion, lässt sich beim »docker pull«-Kommando auf dem Zielhost per Parameter die Überprüfung der Signatur aktivieren. Geschieht – wie bei der Registry-Funktion von Docker üblich – die Kommunikation über HTTPS, darf der auf dem Zielhost laufende Client sicher annehmen, dass das per signiertem Tag aus der Registry geladene Abbild tatsächlich jenes ist, das der Schlüsselinhaber selbst hochgeladen hat – und dass es unverändert ist. Selbst wenn man keine eigene Registry betreibt, ist diese Funktion ausgesprochen praktisch, denn sie funktioniert auch mit anderen, entfernten Registry-Diensten, wenn die Content-Trust-Funktion dort aktiviert ist.

Voraussetzungen

Wer den beschriebenen Image-Workflow nutzt und seine Container auf Basis von jederzeit austauschbaren Container-Abbildern betreibt, sollte allerdings ein wichtiges Detail beachten. Damit das Prinzip überhaupt funktionieren kann, ist es unbedingt notwendig, dass der Container selbst keine persistenten Daten in seinem Overlay-Dateisystem hält – denn die lassen sich sonst nicht auf einen anderen Container übertragen.

Die Voraussetzung lässt sich mit einem Volume aber sehr einfach erfüllen: Ein Volume lässt sich von einem laufenden Container zu jeder Zeit abkoppeln und an einen anderen anschließen.

Fazit

Docker-Container sind als leichtgewichtige Alternative zu echten VMs zumindest theoretisch etwas weniger sicher als KVM & Co., denn die auf Programm-Ebene existierende Trennung ist deutlich weniger scharf. Im Alltag des Administrators fällt das aber kaum ins Gewicht, denn die Bedrohungsszenarien und die möglichen Folgen von Sicherheitsproblemen sind vergleichbar schlimm. Gelingt es dem Angreifer, aus einer VM oder aus einem Container auszubrechen und im schlimmsten Falle Zugriff auf die Ressourcen des Hosts zu erhalten, ist das unstrittig der Super-GAU.

Ähnlich wie bei klassischer Virtualisierung stehen dem Admin aber auch bei Docker Wege offen, dem Horrorszenario vorzubeugen. Das betrifft zunächst Docker selbst: Per TLS und Clientzertifikaten lässt sich unerwünschte externe Kommunikation zuverlässig ausschließen. Relevant ist auch Mandatory Access Control mittels SE Linux oder App Armor, die bei einigen Distributionen ab Werk schon zum Einsatz kommen. Seccomp empfiehlt sich gerade dann, wenn Container mehrerer Kunden auf einem System laufen.

Admins tun obendrein gut daran, die Berechtigungen von Docker-Containern penibel einzuschränken: Zwar findet sich in der Dokumentation vieler Container der explizite Hinweis, dass der Privileged-Modus nötig sei. Ähnlich wie die unsäglichen »wget URL | sudo bash«-Konstrukte, die sich im Netz tausendfach finden, zeugt das jedoch eher von schlechtem Containerdesign als von technischer Notwendigkeit. Gerade weil die Mauer zwischen Container und Host sowie zwischen Container und Container dünner ist als bei echten VMs, ist hier höchste Vorsicht geboten.

Nicht zuletzt ist außerdem die Nutzung zuverlässiger Containerabbilder ein Schlüsselfaktor. Es mag verlockend sein, ein beliebiges Abbild aus dem Docker Hub herunterzuladen und zu starten, weil das in kürzester Zeit möglich ist. Läuft es blöd, hat man dann aber nicht nur den eigentlich erbetenen Dienst auf seiner Hardware, sondern auch noch einen hübschen Bitcoin-Miner oder andere Software, die man nicht will.

Wer viele Docker-Container einsetzt, sollte sich deshalb auch einen passenden CI/CD-Workflow überlegen und ihn auch nutzen, um Container für den Eigenbedarf selber zu bauen. Zumindest sollten Admins ausschließlich auf Abbilder setzen, die aus vertrauenswürdiger Quelle stammen. Neben erhöhter Sicherheit hat dieses Betriebskonzept den Nebeneffekt, dass auch der Betrieb der Container leichter und angenehmer wird.

Fest steht: Docker-Container lassen sich durchaus sicher betreiben, wenn der Admin dem Thema Docker-Sicherheit einiges Hirnschmalz widmet.