Ich beschäftige mich immer wieder damit, wie ich meinen eigenen Server noch ein Stück sicherer machen kann. Auf meinem Debian-Server laufen mittlerweile zahlreiche Dienste in Docker-Containern, darunter Nextcloud, verschiedene Datenbanken und weitere selbst gehostete Anwendungen. Entsprechend wichtig ist mir, dass das System vernünftig abgesichert ist.

Irgendwann bin ich dabei auf das Thema Rootless Docker gestoßen. Die Idee dahinter fand ich interessant: Docker und seine Container betreiben, ohne dass der Docker-Daemon mit Root-Rechten auf dem Host laufen muss. Damit lässt sich eine zusätzliche Sicherheitsebene schaffen.

Also habe ich angefangen, mich mit der Einrichtung zu beschäftigen und zu schauen, wie sich das auf meinem bestehenden Server umsetzen lässt.

Allerdings habe ich das Vorhaben irgendwann wieder aufgegeben. Nicht, weil Rootless Docker grundsätzlich schlecht funktioniert, sondern weil die Umstellung einer bereits umfangreichen Docker-Umgebung doch einige Besonderheiten mit sich bringt. Gerade wenn verschiedene Dienste miteinander kommunizieren, bestimmte Netzwerkfunktionen benötigen oder direkt auf Ressourcen des Hosts zugreifen, muss man sich genauer mit den Einschränkungen beschäftigen.

Bei mir kam irgendwann der Punkt, an dem ich entschieden habe, vorerst bei meiner bisherigen Rootful-Docker-Installation zu bleiben. Mein Server ist bereits durch verschiedene Maßnahmen abgesichert. Dazu gehören unter anderem Firewall-Regeln, eingeschränkte SSH-Zugriffe, regelmäßige Updates und eine möglichst restriktive Konfiguration der Container.

Natürlich bedeutet das nicht, dass Rootful Docker genauso sicher ist wie Rootless Docker. Der zusätzliche Schutz durch einen unprivilegierten Docker-Daemon ist durchaus sinnvoll. Für meine bestehende Umgebung war mir der Aufwand einer vollständigen Umstellung aber letztendlich zu groß.

Trotzdem möchte ich die Anleitung hier veröffentlichen. Vielleicht steht jemand vor einer ähnlichen Entscheidung oder möchte einen neuen Server gleich mit Rootless Docker aufsetzen. Deshalb zeige ich, wie sich Rootless Docker unter Debian und Ubuntu installieren, konfigurieren und testen lässt.

Eines Vorweg: Probiert diese Anleitung aus auf einem frischen System. Auf einem System mit bereits aktivem Rootful Docker kann das nur zur Verwirrung führen. :-)

Was ist Rootless Docker überhaupt?

Normalerweise läuft der Docker-Daemon (dockerd) mit Root-Rechten auf dem Hostsystem. Er verwaltet die Container, erstellt Netzwerke, bindet Speicher ein und kümmert sich um die Kommunikation zwischen den einzelnen Diensten.

Das bedeutet allerdings auch, dass eine Sicherheitslücke im Docker-Daemon oder in der Container-Laufzeit unter Umständen weitreichende Auswirkungen auf das Hostsystem haben kann.

Bei Rootless Docker sieht das anders aus. Hier laufen sowohl der Docker-Daemon als auch die Container innerhalb eines sogenannten User-Namespace ohne Root-Rechte auf dem Host.

Ein User-Namespace sorgt vereinfacht gesagt dafür, dass Benutzer- und Gruppenkennungen innerhalb eines Containers anders zugeordnet werden als auf dem eigentlichen Server.

Ein Prozess kann dadurch innerhalb seines Containers als Root laufen, ohne automatisch die entsprechenden Root-Rechte auf dem Hostsystem zu besitzen.

Wichtig ist dabei eine Unterscheidung: Docker ohne sudo auszuführen bedeutet noch lange nicht, dass Docker rootless läuft.

Wenn ein normaler Benutzer Mitglied der Gruppe docker ist, kann er zwar Docker-Befehle ohne sudo ausführen, erhält über den Docker-Daemon aber praktisch Root-äquivalente Zugriffsmöglichkeiten auf das Hostsystem.

Bei echtem Rootless Docker läuft dagegen bereits der Daemon selbst ohne Root-Rechte.

Das reduziert die möglichen Folgen bestimmter Sicherheitslücken. Eine vollständige Sicherheitsgarantie ist es natürlich trotzdem nicht.

Voraussetzungen für Rootless Docker

Die folgende Anleitung orientiert sich an der offiziellen Docker-Dokumentation und verwendet die Docker-Engine-Pakete aus dem Docker-Repository.

Sie eignet sich für unterstützte Debian- und Ubuntu-Versionen, beispielsweise Debian 12 und 13 sowie Ubuntu 22.04, 24.04 und 26.04 LTS.

Vorausgesetzt wird ein Benutzerkonto mit sudo-Berechtigung und ein System mit systemd.

Zunächst prüfen wir, welches Betriebssystem installiert ist:

cat /etc/os-release

Anschließend schauen wir nach, ob Docker bereits vorhanden ist:

docker --version
docker compose version

Falls Docker bereits über das offizielle Docker-Repository installiert wurde, kann direkt mit der Installation der benötigten Pakete weiter gemacht werden. Allen voran sollte immer ein Backup gemacht werden des laufenden Systems um bei eventuellen Fehlern zurückgehen zu können.

Also unbedingt eine Sicherung der bestehenden Container-Konfigurationen, Datenbanken und Volumes anlegen.

Benötigte Pakete installieren

Für den Rootless-Betrieb benötigen wir einige zusätzliche Komponenten.

sudo apt update
sudo apt install -y \
  uidmap \
  dbus-user-session \
  slirp4netns \
  fuse-overlayfs

Die Pakete haben unterschiedliche Aufgaben.

uidmap stellt die Programme newuidmap und newgidmap bereit. Damit können Benutzer- und Gruppenkennungen innerhalb eines User-Namespace zugeordnet werden.

slirp4netns ermöglicht Netzwerkverbindungen innerhalb einer unprivilegierten Umgebung. fuse-overlayfs stellt einen zusätzlichen Speichertreiber bereit, während dbus-user-session bei der Verwaltung des Benutzer-Dienstes über systemd hilft.

Auf aktuellen Systemen kann Docker häufig direkt den Speichertreiber overlay2 verwenden. fuse-overlayfs ist daher nicht in jeder Konfiguration zwingend erforderlich.

Docker Engine installieren, falls noch nicht vorhanden

Wer Docker bereits aus dem offiziellen Repository installiert hat, kann diesen Abschnitt überspringen.

Für eine Neuinstallation richten wir zunächst das Docker-Repository ein.

sudo apt install -y ca-certificates curl

sudo install -m 0755 -d /etc/apt/keyrings

Anschließend ermitteln wir automatisch, ob Debian oder Ubuntu verwendet wird:

. /etc/os-release

case "$ID" in
  debian)
    DOCKER_DIST=debian
    DOCKER_SUITE="$VERSION_CODENAME"
    ;;
  ubuntu)
    DOCKER_DIST=ubuntu
    DOCKER_SUITE="${UBUNTU_CODENAME:-$VERSION_CODENAME}"
    ;;
  *)
    echo "Diese Anleitung unterstützt Debian und Ubuntu."
    ;;
esac

Die nächsten Befehle nur ausführen, wenn DOCKER_DIST und DOCKER_SUITE korrekt ermittelt wurden.

Jetzt laden wir den offiziellen Signaturschlüssel herunter:

sudo curl -fsSL \
  "https://download.docker.com/linux/${DOCKER_DIST}/gpg" \
  -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc

Danach erstellen wir die Paketquelle:

sudo tee /etc/apt/sources.list.d/docker.sources >/dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/${DOCKER_DIST}
Suites: ${DOCKER_SUITE}
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Nun aktualisieren wir die Paketlisten und installieren Docker inklusive Compose und der Rootless-Komponenten:

sudo apt update

sudo apt install -y \
  docker-ce \
  docker-ce-cli \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin \
  docker-ce-rootless-extras

Wichtig: Diese Installation setzt voraus, dass keine inkompatiblen Docker-Pakete aus anderen Paketquellen installiert sind. Bestehende produktive Docker-Installationen sollten nicht einfach durch eine andere Paketvariante ersetzt werden.

Nach der Installation kann die Docker-Engine zunächst als gewöhnlicher Rootful-Dienst gestartet sein. Die eigentliche Rootless-Konfiguration folgt erst jetzt.

Rootless Docker einrichten

Bevor wir den Rootless-Daemon starten, kontrollieren wir, ob unserem Benutzer die benötigten zusätzlichen Benutzer- und Gruppenkennungen zugewiesen wurden.

grep "^$(whoami):" /etc/subuid
grep "^$(whoami):" /etc/subgid

Eine beispielhafte Ausgabe könnte so aussehen:

dockeruser:231072:65536

Die erste Zahl beschreibt den Anfang des reservierten Bereichs, die zweite die Anzahl der Kennungen.

Docker benötigt für den Rootless-Modus mindestens 65.536 sogenannte subordinate UIDs und GIDs.

Falls die Einträge fehlen, müssen in /etc/subuid und /etc/subgid passende Bereiche eingerichtet werden. Dazu lassen sich die Dateien mit sudoedit bearbeiten:

sudoedit /etc/subuid
sudoedit /etc/subgid

Die eingetragenen Bereiche müssen eindeutig sein und dürfen sich nicht mit bereits vergebenen Bereichen überschneiden. Die Beispielwerte sollten deshalb nicht einfach ungeprüft übernommen werden.

Rootless-Daemon installieren

Jetzt kommt die eigentliche Einrichtung.

Der folgende Befehl wird als normaler Benutzer und ohne sudo ausgeführt:

dockerd-rootless-setuptool.sh install

Falls das Programm nicht gefunden wird, kontrollieren wir zunächst, ob das entsprechende Paket installiert ist:

sudo apt install docker-ce-rootless-extras

Das Setup richtet einen eigenen systemd-Benutzerdienst für Docker ein.

Außerdem wird ein Docker-Kontext mit dem Namen rootless erstellt. Über diesen Kontext weiß die Docker-Kommandozeile, mit welchem Docker-Daemon sie kommunizieren soll.

Falls noch ein Rootful-Daemon läuft, kann das Installationsprogramm darauf hinweisen.

Für einen neuen Server, der vollständig auf Rootless Docker umgestellt werden soll, lässt sich der bisherige Rootful-Dienst deaktivieren:

sudo systemctl disable --now docker.service docker.socket

Achtung: Auf einem bereits produktiv genutzten Server werden dadurch die bisherigen Rootful-Container gestoppt.

Wer Rootless Docker zunächst parallel zur bestehenden Installation testen möchte, kann stattdessen den folgenden Befehl verwenden:

dockerd-rootless-setuptool.sh install --force

Damit lassen sich beide Docker-Daemons nebeneinander betreiben. Sie besitzen allerdings getrennte Container, Images, Netzwerke und Volumes.

Für erste Versuche halte ich diese Variante für sinnvoller, weil man die bestehende Docker-Installation zunächst nicht verändern muss. Dabei muss natürlich darauf geachtet werden, dass sich veröffentlichte Ports nicht überschneiden.

Automatischen Start aktivieren

Damit Rootless Docker auch nach einem Neustart des Servers verfügbar ist, aktivieren wir den Benutzer-Dienst:

systemctl --user enable --now docker

Zusätzlich muss sichergestellt werden, dass der Dienst auch ohne aktive Benutzeranmeldung weiterlaufen darf:

sudo loginctl enable-linger "$(whoami)"

Das ist besonders bei Servern wichtig, auf denen die Container dauerhaft laufen sollen.

Den aktuellen Status kontrollieren wir anschließend mit:

systemctl --user status docker

Und ob das sogenannte Lingering aktiviert ist:

loginctl show-user "$(whoami)" -p Linger

Hier sollte Linger=yes erscheinen.

Die Befehle systemctl --user sollten in einer regulären Benutzersitzung ausgeführt werden, beispielsweise nach einer Anmeldung über SSH. Ein Wechsel mit sudo su kann dazu führen, dass die benötigte systemd-Benutzersitzung nicht richtig erkannt wird.

Prüfen, ob Docker tatsächlich rootless läuft

Jetzt können wir uns die verfügbaren Docker-Kontexte anzeigen lassen:

docker context ls

Anschließend wechseln wir ausdrücklich zum Rootless-Kontext:

docker context use rootless

Die entscheidende Kontrolle erfolgt mit:

docker info

In der Ausgabe sollte unter anderem der Kontext rootless erscheinen.

Noch wichtiger ist der Bereich Security Options. Dort sollte rootless aufgeführt sein.

Wer das gezielt prüfen möchte, kann folgenden Befehl verwenden:

docker info --format '{{json .SecurityOptions}}'

Damit ist sichergestellt, dass wir tatsächlich mit einem Rootless-Daemon verbunden sind und nicht versehentlich weiterhin die Rootful-Installation verwenden.

Falls ein Programm den Docker-Socket nicht automatisch erkennt, lässt sich der Socket auch explizit angeben:

export DOCKER_HOST="unix:///run/user/$(id -u)/docker.sock"

Normalerweise reicht bei aktuellen Docker-Versionen der eingerichtete Docker-Kontext aus. Eine dauerhafte DOCKER_HOST-Variable ist deshalb nicht grundsätzlich notwendig und kann beim Wechsel zwischen verschiedenen Docker-Kontexten sogar für Verwirrung sorgen.

Den ersten Rootless-Container starten

Nachdem die Installation abgeschlossen ist, testen wir zunächst mit dem bekannten Hello-World-Container:

docker run --rm hello-world

Funktioniert das, können wir einen kleinen Webserver starten.

docker run -d \
  --name rootless-test \
  -p 127.0.0.1:8080:80 \
  nginx:alpine

Damit wird ein Nginx-Webserver gestartet, dessen Port 80 innerhalb des Containers auf Port 8080 des Hosts weitergeleitet wird.

Durch die Bindung an 127.0.0.1 ist der Testserver ausschließlich lokal erreichbar.

Wir können ihn mit folgendem Befehl prüfen:

curl -I http://127.0.0.1:8080

Wird eine HTTP-Antwort zurückgegeben, funktioniert die Portweiterleitung.

Danach entfernen wir den Testcontainer wieder:

docker stop rootless-test
docker rm rootless-test

Docker Compose mit Rootless Docker verwenden

Natürlich funktioniert auch Docker Compose.

Wir legen uns zunächst ein Testverzeichnis an:

mkdir -p ~/rootless-test
cd ~/rootless-test

Anschließend erstellen wir eine Datei namens compose.yaml:

nano compose.yaml

Dort tragen wir Folgendes ein:

services:
  nginx:
    image: nginx:alpine
    ports:
      - "127.0.0.1:8080:80"
    restart: unless-stopped

Die Umgebung starten wir mit:

docker compose up -d

Und kontrollieren, ob alles läuft:

docker compose ps

Zum Beenden verwenden wir:

docker compose down

Grundsätzlich lassen sich viele bestehende Compose-Dateien auch unter Rootless Docker verwenden. Allerdings ist nicht garantiert, dass jede Konfiguration unverändert funktioniert.

Vor allem bei speziellen Netzwerkfunktionen, eingebundenen Hostverzeichnissen oder erweiterten Container-Berechtigungen muss man genauer hinschauen.

Welche Einschränkungen gibt es?

Genau an dieser Stelle wurde das Thema für mich interessant, aber auch aufwendiger.

Wer nur einige gewöhnliche Webanwendungen mit einer Datenbank betreibt, wird mit Rootless Docker möglicherweise relativ schnell zurechtkommen.

Bei einer größeren Serverumgebung sieht das allerdings anders aus.

Ports unterhalb von 1024

Unter Linux dürfen normale Benutzer standardmäßig keine Netzwerkports unterhalb von 1024 öffnen.

Das betrifft beispielsweise die Ports 80 und 443, die üblicherweise für HTTP und HTTPS verwendet werden.

Eine einfache Möglichkeit besteht darin, die Container zunächst auf höheren Ports laufen zu lassen und den Zugriff über einen entsprechend konfigurierten Reverse Proxy zu ermöglichen.

Alternativ kann RootlessKit gezielt die Berechtigung erhalten, privilegierte Ports zu öffnen:

sudo setcap cap_net_bind_service=ep \
  "$(command -v rootlesskit)"

Anschließend starten wir den Rootless-Daemon neu:

systemctl --user restart docker

Hier sollte man sich allerdings bewusst sein, dass dadurch eine zusätzliche Berechtigung für das RootlessKit-Programm eingerichtet wird.

Docker dokumentiert auch eine systemweite Lösung über net.ipv4.ip_unprivileged_port_start. Diese erlaubt dann allerdings grundsätzlich auch anderen unprivilegierten Prozessen, entsprechende Ports zu verwenden. Eine solche Änderung würde ich nicht ohne guten Grund vornehmen.

Probleme mit Netzwerkfunktionen

Rootless Docker verwendet eine andere Netzwerkumgebung als der herkömmliche Docker-Daemon.

Container-Netzwerke funktionieren weiterhin, allerdings gibt es Einschränkungen und Unterschiede bei bestimmten Treibern und Netzwerkmodi.

Docker-Overlay-Netzwerke werden im Rootless-Modus beispielsweise nicht unterstützt.

Auch die Erreichbarkeit von Container-IP-Adressen und die Weitergabe der ursprünglichen Client-IP können sich unterscheiden.

Je nach verwendeter Docker- und RootlessKit-Version gibt es dafür unterschiedliche Lösungen. Nicht jede bisherige Netzwerkkonfiguration lässt sich aber unverändert übernehmen.

Gerade bei Anwendungen, die direkt auf spezielle Netzwerkfunktionen des Hosts angewiesen sind, sollte man deshalb vorher prüfen, ob Rootless Docker dafür geeignet ist.

Zugriffsrechte auf Verzeichnisse

Ein weiterer wichtiger Punkt sind die Dateiberechtigungen.

Unter Rootless Docker werden Benutzerkennungen innerhalb der Container über User-Namespaces abgebildet.

Das kann dazu führen, dass ein Container auf ein eingebundenes Verzeichnis nicht mehr wie bisher zugreifen darf.

Besonders bei Datenbanken oder Anwendungen mit bestehenden Datenverzeichnissen ist Vorsicht geboten.

Bevor man Verzeichnisrechte verändert, sollte man prüfen, mit welcher Benutzerkennung die Anwendung läuft und wie diese auf dem Host abgebildet wird.

Ein pauschales chmod 777 oder ein unüberlegtes rekursives chown ist dafür keine saubere Lösung.

Container mit erweiterten Berechtigungen

Nicht jeder Container eignet sich gleichermaßen für den Rootless-Betrieb.

Anwendungen, die auf Hostgeräte, Kernel-Funktionen, bestimmte Netzwerkoperationen oder andere privilegierte Ressourcen zugreifen müssen, können zusätzliche Schwierigkeiten verursachen.

Auch --privileged oder --cap-add funktionieren nicht automatisch so wie bei einer Rootful-Installation. Die vergebenen Berechtigungen bleiben durch den User-Namespace eingeschränkt.

Die Ressourcenbegrenzung über cgroups setzt außerdem eine geeignete Konfiguration mit cgroup v2 und systemd voraus. Selbst dann sind nicht unbedingt sämtliche Controller an den Benutzer delegiert.

Außerdem sollte man beachten, dass nicht alle Sicherheitsmechanismen des Rootful-Betriebs im Rootless-Modus identisch zur Verfügung stehen. Docker nennt beispielsweise Einschränkungen bei AppArmor-Profilen für Container.

Das muss nicht grundsätzlich gegen Rootless Docker sprechen. Man sollte diese Unterschiede aber kennen, bevor man produktive Dienste umzieht.

Bestehende Docker-Container auf Rootless umstellen

Wer bereits Docker nutzt, muss berücksichtigen, dass Rootless Docker einen eigenen Datenbereich verwendet.

Die herkömmliche Rootful-Installation speichert ihre Docker-Daten normalerweise unter:

/var/lib/docker

Rootless Docker verwendet dagegen standardmäßig:

~/.local/share/docker

Auch die Konfigurationsdateien liegen an unterschiedlichen Orten.

Für Rootful Docker ist das üblicherweise:

/etc/docker/daemon.json

Bei Rootless Docker dagegen:

~/.config/docker/daemon.json

Eine vorhandene Rootful-Installation wird deshalb durch die Einrichtung von Rootless Docker nicht automatisch übernommen.

Images müssen gegebenenfalls neu heruntergeladen, Container neu erstellt und bestehende Daten passend migriert werden.

Bei Docker Compose kann man zwar häufig die bisherige compose.yaml als Ausgangspunkt verwenden, trotzdem sollte man die verwendeten Volumes, Portfreigaben, Netzwerke und Berechtigungen kontrollieren.

Ich würde dabei folgendermaßen vorgehen: Zunächst die vorhandenen Konfigurationen und Daten sichern, anschließend die jeweiligen Dienste einzeln in der Rootless-Umgebung testen und erst nach erfolgreicher Prüfung den produktiven Dienst umstellen.

Beide Varianten können während eines Tests parallel existieren. Allerdings dürfen sie nicht unkontrolliert gleichzeitig auf dieselben produktiven Datenbankdateien oder andere gemeinsam genutzte, schreibbare Anwendungsdaten zugreifen.

Zwischen den Docker-Umgebungen lässt sich über die Kontexte wechseln:

docker context use default

Damit wird normalerweise wieder der ursprüngliche Rootful-Daemon angesprochen.

Zurück zur Rootless-Installation geht es mit:

docker context use rootless

Welcher Kontext gerade aktiv ist, lässt sich jederzeit prüfen:

docker context show

Wichtig ist, dass der gewählte Kontext tatsächlich zum richtigen Docker-Socket führt und keine gesetzte Umgebungsvariable die Verbindung überschreibt.

Rootless Docker wieder entfernen

Wer Rootless Docker nur ausprobieren wollte und anschließend zu seiner bisherigen Installation zurückkehren möchte, kann den Rootless-Dienst wieder entfernen.

Zunächst wechseln wir zurück zum Standardkontext:

docker context use default

Anschließend deinstallieren wir den Rootless-Dienst:

dockerd-rootless-setuptool.sh uninstall

Der Befehl entfernt den eingerichteten systemd-Benutzerdienst, löscht aber nicht automatisch die Docker-Images, Volumes und sonstigen Daten der Rootless-Umgebung.

Das ist durchaus sinnvoll, weil dadurch nicht versehentlich Daten verloren gehen.

Wer den Rootful-Daemon vorher deaktiviert hatte, kann ihn wieder aktivieren:

sudo systemctl enable --now docker.service docker.socket

Danach kontrollieren wir den Status:

sudo systemctl status docker
docker --context default ps

Die ursprüngliche Rootful-Installation sollte wieder erreichbar sein, solange ihre Konfigurationen und Daten unverändert geblieben sind.

Das zuvor aktivierte Lingering kann bestehen bleiben. Wenn keine anderen Benutzerdienste darauf angewiesen sind, lässt es sich bei Bedarf mit sudo loginctl disable-linger BENUTZERNAME wieder deaktivieren.

Die Daten der Rootless-Umgebung unter ~/.local/share/docker würde ich erst löschen, wenn wirklich sichergestellt ist, dass sie nicht mehr benötigt werden.

Warum ich bei Rootful Docker bleibe

Nachdem ich mich intensiver mit Rootless Docker beschäftigt hatte, war für mich irgendwann klar, dass ich meine vorhandene Serverumgebung nicht vollständig darauf umstellen möchte.

Es laufen einfach zu viele unterschiedliche Dienste, bei denen ich jeweils kontrollieren müsste, ob die bisherigen Konfigurationen weiterhin funktionieren. Dazu kommen Netzwerke, Speicherverzeichnisse und einige Anwendungen, die besondere Anforderungen haben.

Ich hätte die Umstellung sicherlich weiterverfolgen können. Aber irgendwann muss man auch abwägen, ob der zusätzliche Sicherheitsgewinn den Aufwand für die bestehende Umgebung rechtfertigt.

Bei mir ist Docker bereits durch weitere Maßnahmen abgesichert. Ich achte unter anderem auf möglichst wenige Container-Berechtigungen, den Schutz des Docker-Sockets, Firewall-Regeln, Updates und regelmäßige Datensicherungen.

Besonders wichtig finde ich, dass Container nicht unnötig mit erweiterten Berechtigungen oder Zugriff auf den Docker-Socket betrieben werden. Denn ein unzureichend geschützter Docker-Socket kann bei Rootful Docker weitreichenden Zugriff auf das Hostsystem ermöglichen.

Rootful Docker bleibt trotzdem ein Dienst mit hohen Berechtigungen. Diese Tatsache lässt sich durch zusätzliche Sicherheitsmaßnahmen nicht einfach wegdiskutieren.

Rootless Docker ist deshalb nach wie vor eine interessante Möglichkeit, die Angriffsfläche zu reduzieren.

Wenn ich heute einen neuen Server mit überschaubaren Anforderungen aufsetzen würde, wäre Rootless Docker durchaus wieder eine Überlegung wert.

Bei meiner bestehenden Umgebung bleibe ich vorerst bei dem, was zuverlässig funktioniert und bereits umfangreich abgesichert ist.

Ich wollte die Anleitung trotzdem nicht einfach verwerfen. Vielleicht hilft sie dem einen oder anderen, der sich ebenfalls mit Rootless Docker beschäftigt und seine Container künftig ohne Root-Rechte betreiben möchte.

Quellen und weiterführende Dokumentation

Die Anleitung basiert auf den offiziellen Dokumentationen und deren technischen Voraussetzungen. Da Docker regelmäßig weiterentwickelt wird, lohnt sich vor der Installation ein Blick auf die jeweils aktuellen Hinweise.

Stand der Anleitung: November 2026. Die Einrichtungsschritte orientieren sich an der offiziellen Dokumentation. Die vollständige Migration meiner produktiven Docker-Umgebung habe ich nicht durchgeführt.