Docker-Socket-Mounting: Warum es Root-Zugriff bedeutet und was sicherer ist

1. Was der Docker-Socket eigentlich ist

Der Docker-Daemon dockerd hört normalerweise nicht auf einem Netzwerk-Port, sondern auf einem Unix-Domain-Socket unter /var/run/docker.sock. Jedes Programm, das Lese- und Schreibrechte auf diese Datei hat, kann über sie mit dem Daemon sprechen, exakt dieselbe API, die auch die docker-CLI benutzt. Das ist der Grund, warum der Socket so praktisch wirkt: Ein Tool im Container kann Container auflisten, starten, stoppen oder Images bauen, ohne dass ein eigener Daemon im Container laufen müsste.

Genau diese Bequemlichkeit ist das Problem. Der Socket ist keine eingeschränkte API mit granularen Rechten, sondern ein Vollzugriff auf den kompletten Daemon. Es gibt in der Docker-Engine selbst keine eingebaute Möglichkeit, über den Socket nur lesende Operationen zuzulassen oder einzelne Befehle zu sperren. Wer den Socket erreicht, kann alles tun, was auch ein Administrator per docker-Befehl auf dem Host tun könnte.

# Klassisches Mounting des Docker-Sockets in einen Container
docker run -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  docker:24-cli sh

# Im Container funktioniert docker jetzt, als liefe es auf dem Host
docker ps
docker images
docker info | grep -i "Docker Root Dir"

2. Warum Socket-Zugriff gleich Root-Zugriff ist

Der Docker-Daemon selbst läuft mit Root-Rechten auf dem Host. Jede Anweisung, die er über den Socket entgegennimmt, führt er mit genau diesen Rechten aus. Ein Container, der einen neuen Container über den gemounteten Socket startet, kann dabei beliebige Host-Verzeichnisse als Volume einbinden, zum Beispiel das Wurzelverzeichnis /. Aus Sicht des Daemons ist das ein völlig normaler Befehl, er prüft nicht, ob der Aufrufer selbst schon in einem Container sitzt oder welche Rechte er dort hat.

Damit lässt sich der komplette Isolationsmechanismus von Containern in wenigen Sekunden umgehen. Ein Prozess, der im ursprünglichen Container vielleicht mit eingeschränkten Capabilities und als Non-Root-User läuft, kann über den Socket einen zweiten, hochprivilegierten Container starten, das Host-Dateisystem hineinmounten und sich per chroot effektiv auf dem Host selbst befinden. Sicherheitsmechanismen wie Seccomp-Profile oder ein Read-Only-Root-Filesystem des ersten Containers spielen dabei keine Rolle mehr, weil der zweite Container ohne diese Einschränkungen gestartet werden kann.

3. Typische Anwendungsfälle für Socket-Mounting

Trotz des Risikos ist Socket-Mounting weit verbreitet, weil es einige echte Probleme elegant löst. CI-Runner wie GitLab-Runner oder Jenkins-Agents nutzen es, damit ein Build-Job innerhalb eines Containers selbst wieder Docker-Images bauen und Testcontainer starten kann, ohne dass der komplette Docker-Daemon noch einmal verschachtelt installiert werden muss. Auch Management-Oberflächen wie Portainer oder Watchtower brauchen zwingend Zugriff auf den Socket, weil ihre gesamte Funktion darin besteht, andere Container zu inspizieren, zu aktualisieren oder neu zu starten.

Ein weiterer verbreiteter Fall sind Reverse-Proxy-Lösungen mit automatischer Konfiguration, etwa Traefik oder nginx-proxy, die über den Socket neue Container erkennen und automatisch Routing-Regeln anhand von Labels erzeugen. In all diesen Fällen ist der Socket-Zugriff funktional begründet, nicht nur bequem. Genau deshalb lohnt sich die Frage, ob wirklich der volle Socket nötig ist oder ob eine der im Folgenden beschriebenen Alternativen denselben Zweck mit deutlich kleinerer Angriffsfläche erfüllt.

4. Ein konkretes Angriffsszenario

Um das Risiko greifbar zu machen, hilft ein minimales Beispiel. Angenommen, ein Angreifer erlangt Codeausführung in einem Container, der den Docker-Socket gemountet hat, etwa durch eine verwundbare Abhängigkeit in einer Web-Anwendung. Von dort aus reicht ein einziger docker run-Befehl, um das gesamte Host-Dateisystem einzubinden und eine Root-Shell auf dem Host zu erhalten. Der neue Container muss dafür nicht einmal --privileged gestartet werden, ein einfacher Host-Mount des Wurzelverzeichnisses genügt bereits.

Dieses Szenario ist keine Theorie, sondern ein etabliertes Muster in Penetrationstests und in echten Angriffen auf schlecht abgesicherte CI-Umgebungen. Besonders kritisch wird es, wenn der Container mit dem Socket-Zugriff öffentlich erreichbaren Code ausführt, etwa als Backend einer Web-Anwendung, oder wenn er Third-Party-Images ohne Prüfung startet. In beiden Fällen genügt eine einzige Schwachstelle im Anwendungscode, um aus einem harmlos wirkenden Container heraus die vollständige Kontrolle über den Host zu erlangen.

# Aus einem Container mit gemountetem Docker-Socket heraus:
# Kompletter Host-Ausbruch in einer Zeile
docker run -v /:/host --rm -it alpine chroot /host sh

# Ab hier befindet sich die Shell effektiv auf dem Host,
# mit vollem Lese- und Schreibzugriff auf das gesamte Dateisystem

5. Alternative 1: Docker-in-Docker (DinD)

Bei Docker-in-Docker läuft im Container ein eigener, isolierter Docker-Daemon, statt den Daemon des Hosts über den gemounteten Socket zu nutzen. Damit hat ein kompromittierter Build-Container zwar weiterhin vollen Zugriff auf seine eigene, verschachtelte Docker-Umgebung, aber keinen direkten Zugriff mehr auf den Host-Daemon und die Host-Container. DinD wird meist über das offizielle docker:dind-Image realisiert und ist der Standardweg in vielen CI-Systemen wie GitLab CI, wenn Docker-Befehle innerhalb eines Jobs benötigt werden.

Der Haken an klassischem DinD ist, dass der innere Daemon in der Regel selbst --privileged benötigt, weil er unter anderem eigene Netzwerk-Namespaces, Device-Zugriffe und teils sogar ein eigenes Overlay-Dateisystem verwaltet. Damit verschiebt sich das Risiko, statt komplett zu verschwinden: Ein privilegierter Container kann unter bestimmten Umständen ebenfalls aus seiner Isolation ausbrechen. DinD ist deshalb eine spürbare Verbesserung gegenüber dem direkten Socket-Mount, aber kein Ersatz für eine saubere Rechteanalyse, gerade in Umgebungen mit nicht vertrauenswürdigem Build-Code.

# Docker-in-Docker als eigener, isolierter Daemon starten
docker run --privileged --name dind -d \
  -e DOCKER_TLS_CERTDIR=/certs \
  -v dind-certs:/certs \
  docker:24-dind

# Build-Container verbindet sich ueber TLS mit dem inneren Daemon,
# nicht mit dem Host-Socket
docker run --rm -it \
  --link dind:docker \
  -e DOCKER_HOST=tcp://docker:2376 \
  -e DOCKER_TLS_VERIFY=1 \
  -v dind-certs:/certs:ro \
  docker:24-cli docker ps

6. Alternative 2: Rootless Docker

Rootless Docker verschiebt den Daemon selbst in einen User-Namespace und lässt ihn komplett ohne Root-Rechte auf dem Host laufen. Der entscheidende Unterschied: Selbst wenn ein Angreifer vollen Zugriff auf den Docker-Socket im Rootless-Setup erlangt, landet er im schlimmsten Fall bei den Rechten des unprivilegierten Benutzers, unter dem der Rootless-Daemon läuft, nicht bei Root auf dem Host. Container-IDs werden dabei über User-Namespace-Mapping auf einen Bereich unprivilegierter UIDs abgebildet, sodass UID 0 im Container eben nicht UID 0 auf dem Host entspricht.

Der Preis dafür ist eingeschränkte Funktionalität an einigen Stellen: Bestimmte Netzwerktreiber, Cgroup-Features und Storage-Treiber verhalten sich in Rootless-Umgebungen anders oder stehen gar nicht zur Verfügung, insbesondere wenn der zugrunde liegende Kernel oder die Distribution ältere Konfigurationen mitbringt. Für die meisten CI- und Build-Workloads reicht Rootless Docker aber vollkommen aus, und es ist inzwischen ein offiziell unterstützter Installationsmodus, keine experimentelle Bastellösung mehr.

# Rootless Docker installieren (als normaler Benutzer, nicht root)
curl -fsSL https://get.docker.com/rootless | sh

# Umgebungsvariablen fuer die aktuelle Shell setzen
export PATH=$HOME/bin:$PATH
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock

# Test: laeuft der Daemon ohne root?
docker info | grep -i rootless
ps -o user= -p "$(cat $XDG_RUNTIME_DIR/docker.pid)"

7. Alternative 3: Socket-Proxy mit eingeschränkten Rechten

Wenn ein Tool wie Traefik nur lesend auf Container- und Netzwerkinformationen zugreifen muss, aber niemals selbst Container starten oder Images bauen soll, ist ein Socket-Proxy die passgenaueste Lösung. Ein solcher Proxy, etwa das verbreitete Projekt Tecnativa/docker-socket-proxy, läuft als eigener Container mit dem echten Socket gemountet und stellt selbst wieder einen HTTP-Endpunkt bereit, der nur eine explizit freigegebene Teilmenge der Docker-API durchreicht. Alle anderen Endpunkte werden mit HTTP 403 abgelehnt.

Damit lässt sich präzise steuern, dass ein Container zum Beispiel CONTAINERS=1 zum Lesen von Container-Metadaten bekommt, aber POST=0 gesetzt bleibt und damit keine schreibenden Operationen wie das Starten neuer Container möglich sind. Der eigentliche Anwendungscontainer bekommt nie direkten Zugriff auf /var/run/docker.sock, sondern spricht nur mit dem Proxy über ein internes Docker-Netzwerk. Selbst bei vollständiger Kompromittierung des Anwendungscontainers bleibt der Schaden dadurch auf lesende Operationen begrenzt.

# docker-compose.yml: Socket-Proxy mit minimalen Rechten
services:
  docker-socket-proxy:
    image: tecnativa/docker-socket-proxy:latest
    environment:
      CONTAINERS: 1   # Container auflisten/inspizieren erlaubt
      NETWORKS: 1      # Netzwerke lesen erlaubt
      POST: 0           # keine schreibenden Requests erlaubt
      SERVICES: 0
      TASKS: 0
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - proxy-internal

  traefik:
    image: traefik:v3.0
    environment:
      DOCKER_HOST: tcp://docker-socket-proxy:2375
    networks:
      - proxy-internal

networks:
  proxy-internal:
    internal: true

8. Wenn der direkte Mount unvermeidbar ist

Es gibt Situationen, in denen keine der Alternativen praktikabel ist, etwa bei Legacy-Tools, die fest auf den klassischen Socket-Pfad verdrahtet sind. In solchen Fällen sollten wenigstens flankierende Maßnahmen greifen: Der Socket sollte read-only gemountet werden, wo es die Anwendung zulässt, auch wenn das die Angriffsfläche nur teilweise reduziert, weil viele API-Endpunkte auch über GET-Requests missbraucht werden können. Der Container mit Socket-Zugriff sollte in einem eigenen, möglichst isolierten Netzwerk-Segment ohne Zugriff auf sonstige interne Dienste laufen.

Ebenso wichtig ist es, den Code, der im Container läuft, so vertrauenswürdig wie irgend möglich zu halten, keine ungeprüften Third-Party-Images, keine dynamisch nachgeladenen Skripte, keine öffentlich erreichbaren Endpunkte in genau diesem Container. Zusätzlich empfiehlt sich Monitoring auf ungewöhnliche Docker-API-Aufrufe, etwa über Audit-Logs des Daemons oder ein Tool wie Falco, das verdächtige Socket-Zugriffe in Echtzeit erkennen kann. Diese Maßnahmen ersetzen keine der drei Alternativen, senken aber das Restrisiko, wenn sie unumgänglich sind.

9. Welche Alternative für welchen Fall

Die Wahl zwischen direktem Mount, DinD, Rootless und Socket-Proxy hängt vom konkreten Anwendungsfall ab. Für CI-Pipelines, die selbst Images bauen und testen müssen, ist DinD oder Rootless Docker meist die richtige Wahl, weil hier tatsächlich volle Docker-Funktionalität benötigt wird. Für Monitoring- und Reverse-Proxy-Tools, die nur lesend auf Container-Metadaten zugreifen, ist ein Socket-Proxy fast immer die bessere Wahl, weil er das Prinzip der geringsten Rechte konsequent umsetzt, ohne Funktionalität zu opfern.

Ein pauschales "immer Rootless" oder "immer Proxy" greift zu kurz, weil beide Ansätze unterschiedliche Kompromisse bei Funktionsumfang und Betriebsaufwand mit sich bringen. Die folgende Tabelle fasst die vier besprochenen Ansätze mit ihren jeweiligen Kompromissen zusammen, als praktische Entscheidungsgrundlage für das nächste Setup mit Docker-API-Zugriff aus einem Container heraus.

10. Zusammenfassung

11. FAQ: Docker-Socket-Mounting: Das Wichtigste auf einen Blick