Storage. Backup. Virtualisierung.
Docker-Container · Version 1.11 · © Stor IT Back 2026
Docker ist eine Plattform zur Entwicklung, Bereitstellung und Ausführung von Anwendungen in Containern. Ein Docker-Container stellt eine Anwendung zusammen mit den benötigten Bibliotheken, Laufzeitumgebungen und Konfigurationsdateien in einer weitgehend isolierten Umgebung bereit. Dadurch lassen sich Anwendungen reproduzierbar installieren, aktualisieren und auf unterschiedlichen Systemen betreiben.
Unter Linux nutzt Docker Funktionen des Linux-Kernels wie Namespaces und Control Groups (cgroups). Die Container besitzen dabei keinen eigenen Kernel, sondern verwenden den Kernel des Docker-Hosts gemeinsam. Dies unterscheidet Container grundlegend von klassischen virtuellen Maschinen, die jeweils ein eigenes Betriebssystem mit eigenem Kernel ausführen.
Die häufig genannte Portabilität von Docker gilt deshalb nicht uneingeschränkt: Ein für Linux erstellter Container benötigt eine Linux-Umgebung. Unter Windows können Linux-Container beispielsweise über eine Linux-VM beziehungsweise Docker Desktop betrieben werden. Windows unterstützt außerdem native Windows-Container, diese sind jedoch nicht direkt mit Linux-Containern kompatibel.
Innerhalb vergleichbarer Linux-Umgebungen bietet Docker dagegen eine hohe Portabilität. Ein geeignetes Docker-Image kann auf unterschiedlichen Docker-Hosts weitgehend identisch gestartet werden. Das vereinfacht insbesondere Entwicklung, Test, Deployment und den Betrieb moderner Anwendungen.
Docker kann sicher sein, aber ist nicht automatisch sicher vor Hackern oder vor Schadsoftware. Dabei müssen wir zwei
Gesichtspunkte betrachten:
1. Der Betrieb von Docker-Containern
2. Images aus öffentlichen Repositories
Fangen wir mit dem Betrieb von Containern an. Wichtig ist die Isolation durch den Container.
Docker-Container laufen als Prozesse auf dem Linux-Host und werden unter anderem durch Linux-Namespaces, Control Groups (cgroups), Capabilities und weitere Sicherheitsmechanismen voneinander und vom Host getrennt. Diese Isolation ist jedoch nicht mit der vollständigen Hardware- und Kernel-Isolation einer virtuellen Maschine gleichzusetzen.
Wird der Docker-Daemon aber kompromittiert, so ist das gesamte System gefährdet. Die Container-Engine ist also davon abhängig, dass möglichst
keine Schwachstellen, weder in Docker noch im Betriebssystem, vorhanden sind.
Das Image des Containers ist meist Read-only, das erschwert wenigstens die Manipulation aus dem Container heraus. Weiterhin ist ein Container meist mit weniger
Overhead als eine VM belastet und je weniger nicht benötigter Overhead, desto weniger Schwachstellen.
Die größte Schwachstelle im Betrieb ist wohl eine Fehlkonfiguration, wenn zum Beispiel die REST-API ungesichert offen liegt. Damit verliert man die Kontrolle schneller
als man gucken kann.
Dann noch die Images. Woher kommen die meist? Die wenigsten werden intern oder selbst entwickelte Container nutzen, es sind meist Images aus öffentlichen Repositories. Diese
Repositories sind quasi so etwas wie freie App-Verzeichnisse. Es kann jeder dort die Container herunterladen und starten. An
sich ja noch kein Problem, aber woher stammen die Images in den Repositories? Viele Repositories bieten signierte Images von vertrauenswürdigen Quellen an, besser natürlich
nur Repositories (also private) nutzen, die von einem Hersteller einer Software betrieben wird.
Aber wo ist das eigentliche Problem bei den Containern? Wenn ein vertrauenswürdiger Anbieter eine Software entwickelt und als Container herausbringt, dann nutzt er meist andere
Images als Basis, oder bringt den eigenen Container in einem Stack mit anderen heraus. Also zum Beispiel ein Image für das Betriebssystem, ein anderes Image für Bibliotheken,
dann wieder ein Image für den Webserver und eines für die Datenbank.
Alle diese Images bzw. einzelnen Container bauen aufeinander auf, also die Datenbank braucht das Betriebssystem, der Webserver zusätzlich noch Bibliotheken usw. Genau dafür sind Container
gebaut, ein großer Vorteil für die Flexibilität, aber eine Gefahr für die Integrität des Gesamtsystems. Alle Images und Container in einem Stack müssen sicher sein, damit das Ergebnis sicher ist.
Und das gilt nicht nur für die Installation, sondern auch bei späteren Updates. Wird ein Image kompromittiert, wie soll man das sofort und sicher erkennen? Was ist, wenn
das Datenbank-Image ein anderes Image enthält für die Logverarbeitung? Klar man kann bei der Installation und bei Upgrades sehen, welche Images geladen werden, aber wie soll man das überblicken?
Ein paar grundlegende Hinweise:
:latest im produktiven Betrieb möglichst vermeiden.--privileged starten.
Alles das macht viel Arbeit und drosselt die Flexibilität der Container. Aber es ist unerlässlich für den sicheren Betrieb. Auch kleinere Umgebungen sollten
eine Test-Umgebung betreiben und dort erst einmal alle Updates und Änderungen testen. Wichtig ist bei solch einer Test-Umgebung (bzw. eigentlich Qualitätssicherungs-Umgebung) nicht nur die Funktion
zu prüfen, sondern auch auf seltsame nicht gewünschte Zugriffe nach außen zu überwachen.
Das folgende Beispiel basiert auf einem Debian-System, Docker wird dort über die Paketverwaltung installiert. Eine grundlegende Erklärung zu Docker und
der Container-Virtualisierung mit den Unterschieden zu virtuellen Maschinen und LXC finden Sie in unserer
Container-Einführung zu diesem Thema.
Wichtiger Hinweis:
Dies soll keine
vollständige Anleitung für die Installation und den Betrieb von Docker sein, sondern nur einen Eindruck über die Funktion vermitteln.
Docker-Engine auf Proxmox VE - Installation auf Debian Trixie als VM
Installation der zusätzlich benötigten Pakete (Aktualisierung des Videos):
sudo apt update sudo apt install ca-certificates curl
Docker-GPG-Schlüssel installieren:
sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/debian/gpg \ -o /etc/apt/keyrings/docker.asc sudo chmod a+r /etc/apt/keyrings/docker.asc
Offizielles Docker-Repository hinzufügen:
sudo tee /etc/apt/sources.list.d/docker.sources >/dev/null <<EOF Types: deb URIs: https://download.docker.com/linux/debian Suites: $(. /etc/os-release && echo "$VERSION_CODENAME") Components: stable Architectures: $(dpkg --print-architecture) Signed-By: /etc/apt/keyrings/docker.asc EOF
Paketinformationen aktualisieren und Docker installieren:
sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Damit ist die Docker-Software auf dem Debian-System (Trixie 13, Bookworm 12 oder Bullseye 11) installiert und der Daemon gestartet.
Für eine bequemere Administration kann ein Benutzer der Gruppe docker hinzugefügt
werden. Dadurch können Docker-Kommandos ohne sudo ausgeführt werden.
Sicherheitshinweis: Die Mitgliedschaft in der Gruppe docker gewährt
praktisch administrative beziehungsweise Root-Rechte auf dem Docker-Host. Benutzer sollten daher
nur dann Mitglied dieser Gruppe werden, wenn sie entsprechende Systemrechte erhalten dürfen.
Als Alternative kann für geeignete Umgebungen auch der Rootless-Modus von Docker geprüft werden.
Die Überprüfung der Installation ist sehr einfach, es wird ein Container gestartet.
docker run hello-world
admin@debian:~$ docker run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
Aber woher kommt jetzt dieser Container? Docker prüft zunächst, ob das benötigte Image lokal vorhanden ist. Ist dies nicht der Fall, lädt Docker das Image standardmäßig aus der konfigurierten Registry, bei den üblichen Image-Namen in der Regel aus Docker Hub und startet den Container. Im Docker-Hub sind sehr viele Images vorhanden, einige zum Testen, aber viele auch mit kompletten Anwendungen und Applikationen. Diese Images können direkt genutzt werden, aber auch den eigenen Anforderungen angepasst werden. Es ist sogar möglich, das eigene Image, zum Beispiel mit einer eigenen Anwendung, auf das Docker-Hub hochzuladen. Andere können dann dieses Image selbst nutzen.
Sicherheitshinweis:
Öffentliche Container-Repositories sollten nicht ungeprüft verwendet werden. Eine Untersuchung
von JFrog aus dem Jahr 2024 identifizierte beispielsweise rund 2,8 Millionen verdächtige oder
bösartige öffentliche Docker-Hub-Repositories. Das entsprach zu diesem Zeitpunkt knapp 19 Prozent
der betrachteten öffentlichen Repositories.
Dabei handelte es sich überwiegend nicht um kompromittierte lauffähige Docker-Images. Viele dieser Repositories enthielten überhaupt kein Container-Image, sondern manipulierte Metadaten und Beschreibungen mit Links auf Phishing-Seiten, Malware oder andere unerwünschte Inhalte. Die Untersuchung zeigt dennoch deutlich, warum Herkunft und Vertrauenswürdigkeit von Images und Repositories vor dem produktiven Einsatz geprüft werden sollten.
Nehmen wir ein anderes Beispiel:
docker run -it ubuntu bash
admin@debian:~$ docker run -it ubuntu bash root@f6255860bef0:/# id uid=0(root) gid=0(root) groups=0(root) root@f6255860bef0:/# ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var root@f6255860bef0:/# ps -efa UID PID PPID C STIME TTY TIME CMD root 1 0 0 10:52 pts/0 00:00:00 bash root 12 1 0 10:53 pts/0 00:00:00 ps -efa root@f6255860bef0:/# exit exit
Jetzt wird wieder ein Image heruntergeladen und ein Container mit Ubuntu gestartet mit der Anwendung Bash. Durch die Parameter -it befinden wir uns dann direkt im Container
auf der Bash-Shell. Dort können wir jetzt zum Beispiel den Ubuntu-Container durch weitere Software erweitern.
Ergebnis:
Auf einem installierten Linux System kann innerhalb von weniger als 5 Minuten der erste Container gestartet werden.
Folgende Anforderung: Es sollen mehrere Docker-Container auf einem Server gestartet werden, die jeweils auf Port 80 und 443 hören sollen. Die Verwendung eines
Proxies zur Verteilung der Anfragen über den Domain-Namen ist nicht gewünscht. Die Container sollen direkt angesprochen werden können.
Wo liegt dort das Problem? Bei der standardmäßigen Bridge-Netzwerkkonfiguration besitzen Container interne IP-Adressen.
Von außen veröffentlichte Dienste werden normalerweise über die IP-Adresse des Docker-Hosts und
ein Port-Mapping erreichbar gemacht. Damit ist jeder Port nur einmal nutzbar,
weil auch nur eine IP-Adresse verfügbar ist. Die Kombination Port mit IP-Adresse muss eindeutig sein.
Dieses Problem hat natürlich auch Docker erkannt und dafür nicht nur eine Lösung entwickelt. Wir starten mit dem macvlan-Device. Damit definiert Docker ein Netzwerkelement,
welches eigene IP-Adresse nutzen kann und auch eine MAC-Adresse dafür definiert.
Damit kann jeder Container eine eigene IP-Adresse nutzen, mit einer eigenen individuellen MAC-Adresse.
Wichtig bei MACVLAN: Der Docker-Host kann standardmäßig nicht direkt mit Containern im eigenen MACVLAN-Netzwerk kommunizieren. Dies ist eine Einschränkung des Linux-MACVLAN-Verhaltens. Falls eine Kommunikation zwischen Host und Container erforderlich ist, kann beispielsweise ein zusätzliches MACVLAN-Interface auf dem Host oder eine weitere Bridge-Verbindung eingerichtet werden.
Außerdem muss die Netzwerkinfrastruktur mehrere MAC-Adressen hinter dem verwendeten physischen Interface beziehungsweise Switchport zulassen. Bei sehr vielen MACVLAN-Containern sollte zudem die Anzahl zusätzlicher MAC-Adressen im Netzwerk berücksichtigt werden.
Macvlan bei Docker-Containern - Lösung für Port-Probleme
Hier die Befehle im Video als Copy&Paste:
docker network create -d macvlan --subnet 10.0.0.0/24 --gateway 10.0.0.210 -o parent=ens18 macvlan1
Hierbei muss das Subnet entsprechend dem Subnet am ens18 Device (also der physikalischen Netzwerkkarte) gewählt werden.
Mit parent wird die Netzwerkkarte angegeben, über die der Netzwerkverkehr laufen soll
Das macvlan1 ist der Name des Netzwerkes, welches dann für den Start der Container genutzt wird.
docker run -dit --name http1 --network=macvlan1 --ip 10.0.0.50 httpd:latest
Dieser Befehl startet einen Docker-Container mit dem Namen http1, nutzt das Netzwerk macvlan1 und bekommt die IP-Adresse 10.0.0.50.
docker exec -it http1 bash
Startet eine Bash im Docker-Container http1 mit einem Pseudo-Terminal.
docker container inspect http1
Dieser Befehl zeigt die Konfiguration eines Docker-Containers mit z.B. der Netzwerkeinstellung an.
Einen wichtigen Befehl von Docker haben wir ja schon kennengelernt, es ist run, er startet einen Container (und lädt das Image, wenn es nicht schon vorhanden ist,
auch gleich runter). Dem run-Befehl können auch weitere Parameter mitgegeben werden. Auch da haben wir schon -it gesehen. Dies ruft den Container interaktiv auf und nutzt eine
virtuelle TTY-Schnittstelle. Damit wird man direkt auf dem Container angemeldet.
Aber wenn man nicht alles über die Konsole machen möchte, eine bessere Übersicht benötigt und auch sehr viele Container verwalten muss? Es gibt einen Container, der Container verwalten kann.
Die Anwendung heißt portainer und ist selbst ein Docker-Container. Über diesen Portainer ist eine webbasierte Verwaltung, Überwachung und Installation von Docker-Containern möglich.
Portainer für die Verwaltung von Docker-Containern
Dann weiter mit der Konsole, auch die hat ihre Berechtigung:
Sie können aber auch ein Image einfach nur herunterladen, das geht mit docker pull nginx. Dieser Befehl lädt das Image nginx (ein einfacher Webserver) herunter. Damit ist das
Image auf der lokalen Festplatte, wird aber nicht gestartet. Durch docker run -d --name test-nginx -p 80:80 nginx wird das Image als Container mit dem Namen test-nginx gestartet.
Der Parameter -p gibt den Port auf dem Host-Betriebssystem bzw. dem Container an. Der Webserver wird also auf dem Port 80 des Hosts hören. Ein Browser auf die IP des Hosts zeigt dann
die Test-Seite von nginx an. Der Parameter -d startet den Container im Hintergrund und zeigt die ID an. Docker gibt anschließend die Container-ID zurück.
Für spätere Befehle kann je nach Kommando entweder diese ID oder der vergebene Containername verwendet werden.
admin@debian:~$ docker run -d --name test-nginx -p 80:80 nginx 432689b0af02f0cada32d76c185423f97422c6652c1e6b6dade86caacf232c18 docker: Error response from daemon: driver failed programming external connectivity on endpoint test-nginx (203ecee9df85dfae49658453037c8bb6e789e2c30306c7236d1e2d1f825feae5): Error starting userland proxy: listen tcp 0.0.0.0:80: listen: address already in use. admin@debian:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Also das war jetzt nicht erfolgreich. Was ist passiert? Ganz einfach, der Port 80 wird schon auf dem Host genutzt, dort läuft ein Apache Webserver. Also wurde der Container nicht gestartet. Mit dem Kommando docker ps können wir uns die laufenden Container anzeigen lassen. Es läuft kein Container also war der Start nicht erfolgreich. Korrigieren wir unsere Fehler und nutzen den Port 8080:
admin@debian:~$ docker run -d --name test-nginx -p 8080:80 nginx docker: Error response from daemon: Conflict. The container name "/test-nginx" is already in use by container "432689b0af02f0cada32d76c185423f97422c6652c1e6b6dade86caacf232c18". You have to remove (or rename) that container to be able to reuse that name. See 'docker run --help'. admin@debian:~$ docker rm test-nginx test-nginx admin@debian:~$ docker run -d --name test-nginx -p 8080:80 nginx 5d75bc4aaa730689ad9854b1be57bf4b16c9466a244b2006639b01234de69268 admin@debian:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5d75bc4aaa73 nginx "nginx -g 'daemon of" 18 seconds ago Up 16 seconds 0.0.0.0:8080->80/tcp test-nginx
Schon wieder ein Fehler beim Aufruf des run Kommandos. Wenn der Container mit unserem Namen schon existiert (auch wenn er nicht läuft), dann müsste er entweder einen
anderen Namen bekommen oder wir löschen den ersten Versuch. Und genau das haben wir mit dem Kommando docker rm gemacht. Danach konnte der Container gestartet werden. Mit
dem Kommando docker ps kann man sich die laufenden Container anschauen. Jetzt klappt natürlich auch der Browser-Aufruf und es wird die "Welcome" Seite angezeigt.
Jetzt kommt der große Vorteil der Container: Wenn ich den Webserver jetzt auch noch auf Port 8081 und 8082 benötige, dann starte ich den Container mit neuem Namen und dem
entsprechenden Port einfach noch zwei Mal.
Werden die Container nicht mehr benötigt, so lassen sie sich einfach stoppen und bei Bedarf wieder starten.
admin@debian:~$ docker run -d --name test-nginx1 -p 8081:80 nginx 606b541324e53b5ff8f4909c5bd4b7e86c7e46f81b9f40930991116fd232d55f admin@debian:~$ docker run -d --name test-nginx2 -p 8082:80 nginx 7793025d7cd86b190ea94c8490d9416901ac8abe4cef4b4c51299696ed86637c admin@debian:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7793025d7cd8 nginx "nginx -g 'daemon of" 6 seconds ago Up 4 seconds 0.0.0.0:8082->80/tcp test-nginx2 606b541324e5 nginx "nginx -g 'daemon of" 14 seconds ago Up 12 seconds 0.0.0.0:8081->80/tcp test-nginx1 5d75bc4aaa73 nginx "nginx -g 'daemon of" 8 minutes ago Up 8 minutes 0.0.0.0:8080->80/tcp test-nginx admin@debian:~$ docker stop test-nginx test-nginx1 test-nginx2 test-nginx test-nginx1 test-nginx2 admin@debian:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Für Tests kann ein laufender Container verändert und daraus ein neues Image erzeugt werden. Für produktive und reproduzierbare Umgebungen sollte ein Image jedoch möglichst über ein Dockerfile und einen dokumentierten Build-Prozess erstellt werden. Dadurch sind Änderungen nachvollziehbar, versionierbar und jederzeit reproduzierbar.
Für das Verständnis von Docker ist die Unterscheidung zwischen Image, Container, Layer und Dockerfile wichtig. Ein Docker-Image ist eine schreibgeschützte Vorlage, aus der ein oder mehrere Container gestartet werden können. Das Image enthält beispielsweise die Anwendung, benötigte Bibliotheken, Laufzeitumgebungen und Konfigurationsdateien.
Docker-Images bestehen normalerweise aus mehreren schreibgeschützten Layern. Wird aus einem Image ein Container gestartet, ergänzt Docker diese Layer um eine beschreibbare Container-Schicht. Änderungen während der Laufzeit landen zunächst in dieser beschreibbaren Schicht und verändern das ursprüngliche Image nicht.
Ein Dockerfile wird verwendet, um ein Docker-Image reproduzierbar zu erstellen. Es beschreibt beispielsweise das Basis-Image, zu installierende Pakete, zu kopierende Dateien, Umgebungsvariablen oder den beim Containerstart auszuführenden Prozess. Ein Dockerfile ist jedoch nicht erforderlich, um ein bereits vorhandenes Image auszuführen.
Schauen wir uns erst mal das Image an: Wie würde man einen Container bauen, der die Applikation apache (also den Webserver) nutzt? Nehmen wir einmal an, ein fertiges Image auf dem Docker Hub würde es nicht geben. Dann starten wir mit einem Basis-Image zum Beispiel einer CentOS Basisinstallation. Auf diesem Image sind grundlegende Programme und Libraries enthalten und die Bash als Shell. Dieses Image könnte man dann als Container starten und meldet sich mit dem -it Parameter auf der Bash an. Jetzt kann man wie üblich den apache Webserver installieren, also so, als wäre man auf einem richtigen Server. Läuft der Container jetzt wie gewünscht, dann sind die Änderungen nur im Container, nicht aber im Basis-Image.
Danach kann aus diesem Container
ein neues Image gebaut werden. Es wird dann zum Basis-Image ein neuer Layer für den Apache. Aus diesem neuen Image (Basis Image und Apache Image) können Sie jetzt wieder einen neuen Container
startet. Möchten Sie jetzt eine Webseite oder Anwendung hinzufügen (Container starten und Webseite hinein kopieren), so können Sie auch dann wieder ein neues Image
(Basis Image und Apache Image und Webseite Image) daraus erstellen. Möchten Sie eine andere Webseite in einem Container erstellen, so starten Sie einfach das Basis und Apache Image neu und
fügen die neue Webseite hinzu. Sie können also Images und Container immer wieder verwenden.
Alle Layer des Images sind schreibgeschützt. Beim Start eines Containers legt Docker darüber eine zusätzliche beschreibbare Container-Schicht an.
Dieser oberste Layer (oberstes Image) gehört zur Laufzeit des Containers nicht zum eigentlichen Image,
sondern zum laufenden Container. Wenn Sie also den Container stoppen und dann löschen, so sind alle Änderungen am Image verschwunden. Sie waren im obersten Image Read-write enthalten. Damit können
Container immer wieder frisch aus einem Image gestartet werden. Ein Container besteht aus dem Image und dem beschreibbaren obersten Layer.
Eine Besonderheit bei Docker ist, dass ein Volume in mehrere Container hinein gemountet werden kann.
Identische Image-Layer werden auf einem Docker-Host nur einmal gespeichert und können von
mehreren Images und Containern gemeinsam verwendet werden. Dadurch reduziert Docker den
benötigten Speicherplatz und vermeidet das wiederholte Herunterladen identischer Layer.
In diesem Video installieren wir Paperless NGX mit Portainer. Ein spezielles Thema hierbei sind die Volumes unter Docker. Gerade für ein Dokumentenmanagement
benötigen wir viel Speicherplatz und möchten hierfür sogar ein eigenes Filesystem nutzen. Dies erleichtert die Datensicherung und wir können einen
definierten Speicherplatz nutzen, der nur für Paperless NGX da ist.
Das Video zeigt, wie ein Docker-Container mit Portainer erstellt wird und wie persistente
Speicherbereiche über Docker-Volumes beziehungsweise Bind-Mounts eingebunden werden.
Docker-Volumes speichern persistente Daten außerhalb der beschreibbaren Container-Schicht. Dadurch bleiben die Daten erhalten, wenn ein Container aktualisiert, neu erstellt oder gelöscht wird. Gerade bei Datenbanken, Dokumentenmanagementsystemen und anderen zustandsbehafteten Anwendungen sind Volumes deshalb ein zentraler Bestandteil der Docker-Architektur.
Paperless NGX im Container und Volumes in Docker
Eine Anwendung wäre zum Beispiel der Webbrowser im Container für privates Surfen im Büro. Sie möchten Ihren Mitarbeitern das private Surfen erlauben, aber nicht direkt auf dem Firmenrechner? Auch das könnte im Container laufen. Was sind Probleme beim privaten Surfen in der Firma? Eine Forderung, gerade von der Geschäftsführung, ist häufig die zeitliche Begrenzung der Nutzung, also nur in den Pausen und nach der Arbeit. Aber auch ein Sicherheitsproblem taucht auf, die Verbindungen sind ja alle verschlüsselt, also kann der Firmenproxy den Datenverkehr nicht kontrollieren, er findet keine Viren und sonstige Bedrohungen. Wenn der Mitarbeiter zum privaten Surfen aber einen Container nutzt, dann laufen evtl. Programme (und auch die Viren) in dem Container. Wenn Browser und eventuell heruntergeladene Schadsoftware ausschließlich innerhalb eines entsprechend eingeschränkten Containers ausgeführt werden, kann dies die Isolation gegenüber dem Arbeitsplatzsystem verbessern. Ein Docker-Container ersetzt jedoch keine vollständige Sicherheitsarchitektur und bietet insbesondere keine mit einer getrennten virtuellen Maschine identische Isolation, da Container den Kernel des Hosts gemeinsam nutzen.
Container mit Docker - Sicherer Browser im Container
Docker ist eine Plattform zur Bereitstellung und Ausführung von Anwendungen in Containern. Ein Docker-Container enthält die Anwendung mit ihren benötigten Bibliotheken, Laufzeitumgebungen und Konfigurationsdateien. Unter Linux laufen Container als Prozesse auf dem Host und nutzen gemeinsam dessen Linux-Kernel. Durch Mechanismen wie Namespaces und Control Groups (cgroups) werden die Container voneinander isoliert. Im Unterschied zu einer virtuellen Maschine benötigt ein Container deshalb kein vollständiges eigenes Gastbetriebssystem.
Docker kann unter Debian 13 Trixie über das offizielle Docker-Repository installiert werden. Dazu werden zunächst die benötigten Pakete und der Docker-GPG-Schlüssel eingerichtet und anschließend das Docker-Repository in die Paketverwaltung eingebunden. Danach lassen sich Docker Engine, Docker CLI, containerd, Docker Buildx und das Docker-Compose-Plugin über APT installieren. Mit docker run hello-world kann anschließend geprüft werden, ob Docker korrekt installiert wurde und der Docker-Daemon funktioniert.
Docker kann sicher betrieben werden, ist aber nicht automatisch sicher. Container teilen sich den Kernel des Linux-Hosts und bieten daher eine andere Isolation als virtuelle Maschinen. Für einen sicheren Betrieb sollten Docker Engine und Betriebssystem regelmäßig aktualisiert, nur vertrauenswürdige Images verwendet und Container möglichst ohne Root-Rechte betrieben werden. Zusätzlich sollten unnötige Linux-Capabilities, privilegierte Container und ungeschützte Zugriffe auf die Docker-API vermieden werden. Auch die Netzwerkkommunikation, Ressourcenlimits und persistenten Daten sollten in das Sicherheitskonzept einbezogen werden.
Ja. Ein Benutzer in der Linux-Gruppe docker kann Docker-Kommandos ohne sudo ausführen und erhält damit praktisch sehr weitreichende administrative Rechte auf dem Docker-Host. Über entsprechend konfigurierte Container lassen sich beispielsweise Dateien des Hosts einbinden oder verändern. Deshalb sollten nur vertrauenswürdige Administratoren Mitglied der Docker-Gruppe sein. Für geeignete Umgebungen kann alternativ auch der Rootless-Modus von Docker geprüft werden.
Ein Docker-Image ist eine schreibgeschützte Vorlage für einen Container. Es enthält beispielsweise Anwendung, Bibliotheken und Konfigurationsdateien und besteht meist aus mehreren Layern. Ein Docker-Container ist eine laufende Instanz dieses Images. Beim Start ergänzt Docker die schreibgeschützten Image-Layer um eine beschreibbare Container-Schicht. Wird der Container gelöscht, geht diese Laufzeitschicht verloren, sofern die Daten nicht in einem Volume oder Bind-Mount gespeichert wurden.
Ein Dockerfile ist eine Textdatei mit Anweisungen zum reproduzierbaren Erstellen eines Docker-Images. Darin kann beispielsweise festgelegt werden, welches Basis-Image verwendet wird, welche Pakete installiert, welche Dateien kopiert und welcher Prozess beim Start ausgeführt wird. Ein Dockerfile wird zum Bauen eines Images benötigt, nicht jedoch zum Starten eines bereits vorhandenen Images. Für produktive Umgebungen sind Dockerfiles sinnvoll, weil Änderungen dokumentiert, versioniert und reproduzierbar umgesetzt werden können.
Der Tag latest bezeichnet keine fest definierte Softwareversion und kann sich ändern, wenn der Hersteller oder Maintainer ein neues Image veröffentlicht. Dadurch kann ein erneuter Download eines Images unbemerkt eine andere Softwareversion enthalten. Für produktive Systeme sollten deshalb möglichst konkrete Versions-Tags oder noch genauer Image-Digests verwendet werden. Dadurch werden Deployments reproduzierbarer und Updates können kontrolliert getestet werden.
Docker-Images können mit Vulnerability-Scannern wie Docker Scout oder Trivy auf bekannte Schwachstellen untersucht werden. Dabei werden unter anderem Betriebssystempakete und Software-Abhängigkeiten mit Datenbanken bekannter Sicherheitslücken abgeglichen. Ein solcher Scan sollte nicht nur vor der ersten Installation erfolgen, sondern regelmäßig wiederholt werden, da auch ältere und unveränderte Images nachträglich von neu entdeckten Schwachstellen betroffen sein können. Zusätzlich sollten Herkunft, Publisher und verwendete Basis-Images geprüft werden.
Mit dem Docker-Netzwerktreiber MACVLAN kann ein Container eine eigene MAC-Adresse und eine eigene IP-Adresse im physischen Netzwerk erhalten. Der Container kann dadurch im LAN ähnlich wie ein eigenständiger Server angesprochen werden. Das ist beispielsweise sinnvoll, wenn mehrere Container denselben TCP-Port wie 80 oder 443 verwenden sollen, ohne die Dienste über unterschiedliche Ports des Docker-Hosts oder einen Reverse Proxy bereitzustellen. Die verwendete Netzwerkinfrastruktur muss dabei mehrere MAC-Adressen hinter dem betreffenden Switchport zulassen.
Bei Linux-MACVLAN ist eine direkte Kommunikation zwischen dem physischen beziehungsweise übergeordneten Host-Interface und den daran angebundenen MACVLAN-Interfaces standardmäßig nicht vorgesehen. Deshalb kann ein Docker-Container in einem MACVLAN-Netzwerk den Docker-Host über dieses Netzwerk normalerweise nicht direkt erreichen. Wenn diese Kommunikation benötigt wird, kann beispielsweise auf dem Host ein zusätzliches MACVLAN-Interface eingerichtet oder eine andere Netzwerkarchitektur verwendet werden.
Docker-Volumes und Bind-Mounts speichern Daten außerhalb der flüchtigen Container-Schicht. Ein Docker-Volume wird von Docker verwaltet und befindet sich in einem von Docker kontrollierten Speicherbereich. Bei einem Bind-Mount wird dagegen ein konkretes Verzeichnis oder eine Datei des Hostsystems direkt in den Container eingebunden. Volumes sind für viele Anwendungen die einfachere und besser von Docker verwaltbare Lösung, während Bind-Mounts mehr Kontrolle über den Speicherort auf dem Host ermöglichen.
Daten in der beschreibbaren Laufzeitschicht eines Containers gehen verloren, wenn der Container gelöscht wird. Persistente Anwendungsdaten sollten deshalb in Docker-Volumes oder Bind-Mounts gespeichert werden. Diese Daten bleiben unabhängig vom Lebenszyklus des Containers erhalten. Das ist besonders wichtig für Datenbanken, Dokumentenmanagementsysteme und andere Anwendungen mit dauerhaft zu speichernden Daten.
Docker Compose ermöglicht es, mehrere zusammengehörige Container, Netzwerke, Volumes und weitere Einstellungen deklarativ in einer YAML-Datei zu beschreiben. Statt mehrere lange docker run-Befehle einzeln auszuführen, kann eine komplette Anwendung beispielsweise mit docker compose up -d gestartet werden. Docker Compose eignet sich besonders für Anwendungen, die aus mehreren Diensten wie Webserver, Datenbank und Backend bestehen. Die Compose-Datei kann außerdem versioniert und für ein reproduzierbares Deployment genutzt werden.
Bei der Datensicherung von Docker sollte nicht primär der laufende Container gesichert werden. Wichtig sind vor allem die persistenten Daten in Volumes und Bind-Mounts sowie Dockerfiles, Compose-Dateien und weitere Konfigurationsdateien. Datenbanken sollten möglichst anwendungskonsistent gesichert werden. Auch Secrets und externe Konfigurationen müssen in das Backup-Konzept einbezogen werden. Ein vollständiges Docker-Backup sollte nicht nur erstellt, sondern durch regelmäßige Restore-Tests überprüft werden.
Portainer stellt eine webbasierte grafische Oberfläche für die Verwaltung von Container-Umgebungen bereit. Darüber lassen sich unter anderem Docker-Container, Images, Netzwerke und Volumes anzeigen und verwalten. Für Administratoren kann Portainer insbesondere bei mehreren Containern die Übersicht gegenüber einer ausschließlich kommandozeilenbasierten Administration verbessern. Sicherheitsrelevante Einstellungen und Zugriffsrechte sollten jedoch auch bei einer grafischen Verwaltung sorgfältig geplant werden.
