Begriff
Docker Socket
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Der Docker Socket (/var/run/docker.sock) ist das Ohr des Docker Daemons.
Hier hört er auf Befehle.
Normalerweise flüstert nur der docker CLI Befehl ("Starte Container!") in dieses Ohr.
Aber: Du kannst dieses Ohr auch in einen Container hineinlegen (mounten).
Warum?
Damit ein Container (z. B. Jenkins oder Portainer) andere Container steuern kann.
"Ich bin Jenkins (im Container) und ich will einen Test-Container starten."
Das nennt man Docker-in-Docker (via Socket Binding).
Merksatz: Ein Unix-Domain-Socket, der als primäre Kommunikationsschnittstelle für die Docker-API dient. Zugriff auf diesen Socket ist gleichbedeutend mit Root-Zugriff auf dem Host-System.
In docker-compose.yml für Monitoring-Tools:
services:
portainer:
image: portainer/portainer
volumes:
- /var/run/docker.sock:/var/run/docker.sock
Jetzt kann Portainer alle Container auflisten und stoppen. Ohne diesen Mount wäre Portainer blind.
Praxisroutine
In der Praxis lernst du Docker Socket, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.
Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.
1. Das Sicherheits-Desaster (Root Escalation)
Den Socket zu mounten ist brandgefährlich.
Beweis:
Ich bin Hacker im Container jenkins (non-root).
Ich sehe /var/run/docker.sock.
Ich installiere docker CLI.
Ich tippe: docker run -v /:/host alpine cat /host/etc/shadow.
Der Daemon (draußen!) führt das aus. Er mountet die Host-Festplatte in den neuen Alpine-Container.
Ich lese das Passwort vom Host-Admin.
Fazit: Wer den Socket hat, hat den Host.
2. Socket Proxy (Die Lösung)
Wenn du Container-Metriken brauchst (Traefik, Prometheus), aber keine Schreibrechte geben willst.
Nutze einen Socket Proxy (z. B. Tecnativa).
Das ist ein kleiner Container dazwischen.
Er leitet GET /containers/json weiter (Erlaubt).
Er blockiert POST /containers/create (Verboten).
Damit kann Traefik Labels lesen, aber nichts kaputtmachen.
3. TCP Socket (-H tcp://)
Du kannst den Socket auch übers Netzwerk freigeben (Port 2375/2376). Tue das niemals im offenen Internet ohne mTLS (Zertifikate). Bots scannen das Internet nach Port 2375. Innerhalb von Sekunden installieren sie Crypto-Miner auf deinem Cluster. Standard: "Bind to localhost only".
1. Unix Domain Socket Permissions & Group-IDs
Der Docker-Socket (/var/run/docker.sock) ist technisch ein Inter-Process Communication (IPC) Socket. Er gehorcht strikten POSIX File-Permissions (meist srw-rw---- root:docker).
Mountet man ihn als Volume via -v in einen Pod/Container, erbt der Zielprozess exakt dieses Berechtigungs-Set der Host-Inode. Läuft der Jenkins-User im Container unter der UID 1000 ohne GID Zugehörigkeit zum Host-docker (GID oft 999), knallt der Aufruf mit "Permission Denied".
Entwickler machen dann den fatalen Fehler und setzen ein verzweifeltes chmod 777 /var/run/docker.sock zur Laufzeit auf dem Host, womit schlichtweg jeder kompromittierte Redis-Deamon im Cluster das System bedingungslos übernehmen und root-Level Ausbrüche durch Container-Spin-Ups forcieren kann.
2. Rootless Docker & Sysbox
Das "Wer den Socket hat, ist Gott"-Dogma verfällt mit der Cloud-Native Security Era.
Durch Rootless-Docker und v2 Cgroups operiert der gesamte Docker Daemon ( dockerd) selbst im User-Space ohne Host-Root Rechte. Wenn ein Hacker hier den Socket schnappt und -v /:/host fährt, mountet er maximal das isolierte Filesystem des unprivilegierten Users.
Darüber hinaus nutzt man echte Sandboxes wie Sysbox OCI Runtimes: Hier ist der Daemon so isoliert von Kernel-Ring 0, dass ein Container-interner Docker-Daemon (DinD) völlig sicher, und ohne das unsägliche --privileged Flag oder das Leaken des Host-Sockets in Kubernetes laufen kann, da Sysbox das Namespace-Nesting für /dev nativ vortäuscht.
3. API-Filterung mittels eBPF / mTLS Gateways
Ist der direkte Host-Socket zwingend (z.B. bei Traefik Edge Routern) verbietet man das Raw-Binding durch Reverse-Proxy Injection.
Man platziert Services wie docker-socket-proxy im selben internen Network. Der Proxy lauscht auf Socket-Mounts, veröffentlicht das Docker HTTPS/REST API über TLS 1.3 im Container-Network, kappt aber rigoros HTTP POST, DELETE und PUT Requests (Read-Only Mode) in seinem HAProxy Modul.
Noch härteres Engineering verlegt dies durch eBPF Kernel Hooks: Bevor das JSON Paket am Unix-Socket überhaupt beantwortet wird, decodieren Kernel-Routinen (wie Tetragon) die Socket-Payload, verbieten Schreibzugriffe applikativ in Mikrosekunden und fälschen Zero-Trust-Logs in Elastic.
Quick-Check
Was ist
DooD?Docker-out-of-Docker. Das Verfahren, den Socket zu mounten (-v /var/run/docker.sock:...), damit der Container den Host-Docker nutzt. Im Gegensatz zu "DinD" (Docker-in-Docker), wo wirklich ein neuer Daemon im Container läuft (verschachtelt, langsam, privilegiert). DooD ist meist performanter.Dateirechte?
Der Socket gehörtroot:docker. Deshalb musst du deinen User zur Gruppedockerhinzufügen (usermod -aG docker user), um ohnesudodocker nutzen zu können. (Warnung: Das macht deinen User effektiv zum Root-User).Windows Named Pipe?
Auf Windows gibt es keine Unix Sockets. Dort heißt es//./pipe/docker_engine. Das Prinzip (API Endpoint) und das Risiko sind identisch.