Docker Rootless Mode auf Debian und Ubuntu einrichten

Ein Fehler im Docker-Daemon oder ein Container-Ausbruch soll nicht sofort volle Root-Rechte auf dem Host bedeuten. Docker Rootless Mode betreibt Daemon und Containerprozesse im Benutzerkontext und bleibt 2026 ein sinnvoller Härtungsbaustein für Debian- und Ubuntu-Hosts.

Rootless Mode ist nicht dasselbe wie Zugriff auf einen Root-Daemon über die Gruppe docker. Deren Mitglieder können Container mit Host-Verzeichnissen und weitreichenden Fähigkeiten starten, praktisch gleichwertig zu Root-Rechten. Beim Rootless-Betrieb läuft auch dockerd ohne Root. Vorhandene Docker-Grundlagen erklärt die Anleitung zur Docker-Installation unter Linux.

1. Funktionsweise und Grenzen verstehen

Docker nutzt für Rootless Linux User Namespaces und RootlessKit. Der Benutzer erhält einen Bereich untergeordneter IDs, innerhalb des Namespace kann ein Prozess wie Root erscheinen, außerhalb bleibt er auf diesen Bereich beschränkt. Für das Netzwerk wird typischerweise RootlessKit zusammen mit slirp4netns verwendet.

Variante	Daemon	Berechtigungsmodell	Typischer Einsatz
Docker mit Root-Daemon	läuft als Root	Zugriff über `sudo` oder Gruppe `docker`	Hosts mit Anforderungen an alle Docker-Funktionen
Docker Rootless Mode	läuft als normaler Benutzer	User Namespace, eigener Socket und eigener Context	Entwicklung, CI und gehärtete Einzelbenutzer-Hosts
Nur Non-Root-Benutzer im Container	kann weiterhin als Root laufen	reduziert Rechte im Container, ändert aber den Daemon nicht	zusätzliche Härtung für jedes Image

Rootless ist keine vollständige Sicherheitsgrenze. Unsichere Images und verwundbare Anwendungen bleiben Risiken. Weitere Maßnahmen behandelt Docker Compose mit Secrets, Healthchecks und Non-Root absichern.

2. Voraussetzungen auf Debian oder Ubuntu installieren

Die Einrichtung erfolgt pro Benutzer. Als dieser Benutzer anmelden, das Setup-Skript niemals mit sudo ausführen. Zuerst die Werkzeuge für untergeordnete IDs, die systemd-Benutzerinstanz und das Rootless-Netzwerk installieren:

sudo apt update
sudo apt install -y uidmap dbus-user-session slirp4netns

Aus dem offiziellen Docker-Repository liefert das Paket docker-ce-rootless-extras die Rootless-Werkzeuge. Fehlt dockerd-rootless-setuptool.sh, dieses Paket nachinstallieren:

command -v dockerd-rootless-setuptool.sh
sudo apt install -y docker-ce-rootless-extras
command -v dockerd-rootless-setuptool.sh

Die letzte Ausgabe sollte einen Pfad wie /usr/bin/dockerd-rootless-setuptool.sh zeigen. newuidmap und newgidmap aus dem Paket uidmap ebenfalls prüfen:

command -v newuidmap
command -v newgidmap

3. Untergeordnete UID- und GID-Bereiche prüfen

Docker verlangt für den Rootless-Benutzer mindestens 65.536 untergeordnete UIDs und ebenso viele GIDs. Die Bereiche stehen in /etc/subuid und /etc/subgid. Die Startnummer darf abweichen. Entscheidend sind ein eindeutiger Bereich und eine Länge von mindestens 65.536.

USER_NAME="$(id -un)"
grep "^${USER_NAME}:" /etc/subuid
grep "^${USER_NAME}:" /etc/subgid

Eine passende Ausgabe sieht beispielsweise so aus:

containeradmin:100000:65536

Fehlen die Einträge, weist ein Administrator freie Bereiche zu, nach Prüfung dass sie keinem anderen Benutzer gehören. Das Beispiel nutzt Bereich ab 100000, nur übernehmen wenn dieser frei ist:

sudo usermod --add-subuids 100000-165535 "$(id -un)"
sudo usermod --add-subgids 100000-165535 "$(id -un)"
grep "^$(id -un):" /etc/subuid
grep "^$(id -un):" /etc/subgid

Nach einer Änderung vollständig ab- und wieder anmelden, laufende Sitzungen übernehmen die Zuordnung sonst nicht zuverlässig.

4. Rootless-Daemon installieren

Einen vorhandenen systemweiten Docker-Daemon nur stoppen, wenn er nicht mehr gebraucht wird. Rootful und Rootless können parallel laufen, aber Context-Verwechslungen und Portkonflikte werden wahrscheinlicher. Für einen reinen Rootless-Testhost den Root-Daemon anhalten:

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

Starten Sie anschließend als normaler Benutzer die Einrichtung:

dockerd-rootless-setuptool.sh install

Das Skript erzeugt einen systemd-Benutzerdienst, startet den Daemon und legt den Docker Context rootless an. Nicht blind alte Werte aus fremden Anleitungen übernehmen, sondern den erzeugten Context prüfen:

docker context ls
docker context use rootless
docker context show

Die letzte Ausgabe muss rootless lauten. Alternativ kann ein Programm den Socket direkt ansprechen. Die Variable gilt nur für die aktuelle Shell:

export DOCKER_HOST="unix:///run/user/$UID/docker.sock"
docker info

DOCKER_HOST hat Vorrang vor dem Context. Im Alltag entweder Context oder Variable bewusst nutzen.

5. Benutzer-Service und Autostart konfigurieren

Der Daemon wird über die systemd-Instanz des Benutzers verwaltet. Die folgenden Befehle brauchen kein sudo:

systemctl --user status docker
systemctl --user enable docker
systemctl --user restart docker
journalctl --user -u docker --no-pager -n 100

Ohne aktive Anmeldung beendet die Distribution Benutzer-Dienste oft. Soll Docker nach dem Abmelden weiterlaufen, aktiviert ein Administrator Linger:

sudo loginctl enable-linger "$(id -un)"
loginctl show-user "$(id -un)" -p Linger

Erwartet wird Linger=yes. Das ist eine bewusste Betriebsentscheidung für Mehrbenutzersysteme.

6. Installation technisch verifizieren

Eine erfolgreiche Installation zeigt sich erst nach einem echten Containerstart und Host-Prüfungen ohne sudo:

docker context show
docker info --format '{{json .SecurityOptions}}'
docker run --rm hello-world
docker run --rm alpine id
ps -u "$(id -un)" -o pid,user,cmd | grep '[d]ockerd'
stat -c '%U %G %a %n' "/run/user/$UID/docker.sock"

Die Security Options müssen name=rootless enthalten, hello-world erfolgreich enden. Meldet Alpine im Container uid=0(root), ist das kein Widerspruch: UID 0 liegt im Container-Namespace und wird außerhalb auf eine untergeordnete Host-UID abgebildet. dockerd und Socket müssen dem angemeldeten Benutzer gehören.

Zusätzlich prüfen, dass der Client nicht Root-Daemon nutzt:

docker context inspect rootless
printf 'DOCKER_HOST=%s\n' "${DOCKER_HOST:-nicht gesetzt}"
docker info --format 'Rootless={{json .SecurityOptions}} DockerRootDir={{.DockerRootDir}}'

7. Compose, Ports und persistente Daten testen

Docker Compose verwendet den aktiven Context. Ein minimales Beispiel veröffentlicht einen unprivilegierten Host-Port und prüft Neustart sowie Logs:

mkdir -p ~/rootless-test
cd ~/rootless-test
printf '%s\n' \
  'services:' \
  '  web:' \
  '    image: nginx:alpine' \
  '    ports:' \
  '      - "8080:80"' \
  '    restart: unless-stopped' > compose.yaml
docker compose up -d
docker compose ps
curl -I http://127.0.0.1:8080
docker compose logs --tail=20
docker compose down

Ports unter 1024 sind standardmäßig gesperrt. Ports ab 1024 nutzen oder einen Reverse Proxy davorsetzen. Docker dokumentiert alternativ CAP_NET_BIND_SERVICE für rootlesskit oder eine Absenkung von net.ipv4.ip_unprivileged_port_start, beides nur nach Sicherheitsprüfung einsetzen.

Volumes und Bind Mounts bleiben an die Rechte des Rootless-Benutzers gebunden, Schreibzugriffe per Testverzeichnis prüfen. Ausführlich dazu Docker-Netzwerke und Volumes verstehen.

mkdir -p ~/rootless-data
docker run --rm -v "$HOME/rootless-data:/data" alpine sh -c 'date > /data/test.txt'
ls -ln ~/rootless-data/test.txt
cat ~/rootless-data/test.txt

8. Ressourcenlimits und cgroup v2 prüfen

CPU-, Arbeitsspeicher- und Prozesslimits funktionieren im Rootless-Betrieb zuverlässig, wenn cgroup v2 aktiv ist und systemd die benötigten Controller an den Benutzer delegiert. Ohne diese Voraussetzungen ignoriert Docker einzelne Begrenzungen möglicherweise oder meldet sie als nicht unterstützt.

stat -fc %T /sys/fs/cgroup
systemctl --user show docker -p Delegate
docker info | grep -E 'Cgroup Driver|Cgroup Version|WARNING'
docker run --rm --memory=256m --cpus=0.50 alpine sh -c 'cat /sys/fs/cgroup/memory.max; cat /sys/fs/cgroup/cpu.max'

Bei cgroup v2 lautet die erste Ausgabe cgroup2fs, Docker meldet Version 2 und den systemd-Treiber. Ob alle Controller verfügbar sind, hängt von Distribution und systemd-Konfiguration ab. Produktive Limits deshalb mit einem Testcontainer verifizieren, nicht nur per Compose-Datei annehmen.

9. Häufige Fehler systematisch beheben

newuidmap fehlt: Paket uidmap installieren und den Pfad erneut prüfen.
Zu wenige subordinate IDs: Einträge in /etc/subuid und /etc/subgid auf mindestens 65.536 IDs erweitern, Überschneidungen vorher ausschließen.
systemctl --user erreicht den Bus nicht: dbus-user-session installieren, neu anmelden und die Benutzer-Sitzung prüfen.
Client meldet keine Verbindung: Context mit docker context show sowie Socket unter /run/user/$UID/docker.sock kontrollieren.
Falscher Daemon antwortet: DOCKER_HOST leeren oder korrekt setzen und anschließend docker context use rootless ausführen.
Dienst endet nach Logout: Linger gezielt mit loginctl enable-linger aktivieren.
Port 80 oder 443 schlägt fehl: einen Port ab 1024 verwenden oder einen privilegierten Reverse Proxy vorschalten.
Ressourcenlimit greift nicht: cgroup v2, systemd-Delegation und Warnungen in docker info prüfen.
Bind Mount ist nicht beschreibbar: Eigentümer und Modus des Host-Verzeichnisses für den Rootless-Benutzer korrigieren.
Netzwerkleistung weicht ab: verwendeten RootlessKit-Netzwerktreiber und slirp4netns-Version prüfen.
Setup soll entfernt werden: zuerst Container und Daten sichern, dann dockerd-rootless-setuptool.sh uninstall nutzen. Daten werden dadurch nicht automatisch vollständig gelöscht.

10. Sicherheitscheck für den Dauerbetrieb

Rootless reduziert die Folgen vieler Fehlkonfigurationen, ersetzt aber keine Pflege des Hosts und der Images. Vor dem produktiven Einsatz sollte die folgende Liste vollständig abgearbeitet sein:

Rootless-Context ist aktiv und in docker info bestätigt.
Der Benutzer besitzt nur die notwendigen Host-Dateirechte.
Container laufen zusätzlich mit einer festen Non-Root-UID, soweit das Image dies unterstützt.
Images stammen aus bekannten Quellen und werden regelmäßig aktualisiert sowie gescannt.
Keine unnötigen Ports sind an alle Host-Adressen gebunden.
Secrets stehen nicht im Image, in der Compose-Datei oder in allgemein lesbaren Umgebungsdateien.
Backups umfassen Volumes, Konfiguration und einen getesteten Wiederherstellungsweg.
Logs des Benutzer-Dienstes werden überwacht und Speichergrenzen kontrolliert.
cgroup-Limits wurden praktisch verifiziert.
Die Mitgliedschaft in der Gruppe docker wurde entfernt, wenn kein Root-Daemon mehr verwendet wird.

Der Nachweis besteht aus drei Punkten: dockerd gehört dem normalen Benutzer, der aktive Context zeigt auf dessen Socket, und docker info meldet Rootless als Security Option.

Quellen

Docker Docs: Rootless mode, offizielle Dokumentation zu Voraussetzungen, Installation, systemd, Ports und cgroup.
OneUptime: Docker Rootless Mode, ergänzende Praxisdarstellung aus 2026.
Panelica: Docker Rootless Mode Security Guide 2026, ergänzende Sicherheits- und Betriebsaspekte.