Projekt Phoenyx – Teil 5: Der unsichtbare Wächter (Socket Proxy)

Warum dieser Schritt lebenswichtig ist

Wir bereiten uns auf die Installation von Traefik vor. Traefik ist genial, weil es „magisch“ erkennt, wenn wir einen neuen Docker-Container starten. Aber damit diese Magie funktioniert, muss Traefik mit dem Docker-Daemon sprechen. Und hier liegt die Gefahr.

Würden wir Traefik diesen Generalschlüssel geben und Traefik hätte eine Sicherheitslücke, könnte ein Angreifer über Traefik jeden beliebigen Container starten – auch einen, der ihm vollen Zugriff auf das Dateisystem deines Hosts gibt.

Die Lösung: Tecnativa Socket Proxy

Wir schalten einen „Filter“ dazwischen. Wir nutzen dafür den hervorragenden Docker Socket Proxy von Tecnativa. Es ist ein kleiner, spezialisierter HAProxy-Container, der den echten Socket nimmt und eine „entschärfte“ Version davon in einem internen Netzwerk bereitstellt.

Die Konfiguration erklärt

Hier ist die socket-proxy-docker-compose.yml:

services:
  socket-proxy:
    image: tecnativa/docker-socket-proxy
    environment:
      CONTAINERS: 1  # Erlaubt: "Zeig mir alle Container"
      NETWORKS: 1    # Erlaubt: "Zeig mir alle Netzwerke"
      SERVICES: 1    # Erlaubt: "Zeig mir Services"
      TASKS: 1
      POST: 0        # VERBOTEN: "Erstelle/Lösche etwas"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - socket_proxy

Was passiert hier?
Wir setzen die Variablen auf 1 (erlaubt) oder 0 (verboten). Das Wichtigste ist POST: 0. HTTP POST-Requests werden genutzt, um Daten zu senden oder Aktionen auszulösen (z.B. „Starte Container X“). Indem wir das verbieten, machen wir den Socket „Read-Only“. Traefik kann gucken, aber nicht anfassen.

Exkurs: Wo ist die „networks“ Sektion?

Vielleicht ist dir etwas aufgefallen: In der Datei oben verweisen wir auf das Netzwerk socket_proxy, aber wir definieren es nirgendwo am Ende der Datei (kein networks: ... Block auf oberster Ebene).

Warum funktioniert das?

Das ist die Magie der Docker Compose Includes, die wir in Teil 4 besprochen haben. Docker macht Folgendes beim Start:

1. Es liest die Master-Datei (docker-compose.yml).
2. Es lädt zuerst die networks/network.yml (dort sind ALLE Netzwerke definiert).
3. Es lädt danach die socket-proxy-docker-compose.yml.
4. Es „schmilzt“ alles zu einer einzigen, riesigen Konfiguration zusammen.

Da das Netzwerk socket_proxy bereits im „Gesamt-Paket“ durch die network.yml bekannt ist, müssen (und sollten) wir es im Service-File nicht noch einmal neu definieren. Das verhindert Redundanz und stellt sicher, dass alle Dienste exakt dieselben Netzwerke nutzen.

Ausblick

Unser Sicherheits-Fundament ist gelegt. Jetzt können wir Traefik installieren und ihn mit diesem sicheren Socket verbinden, ohne Angst vor einer Kompromittierung des gesamten Hosts haben zu müssen.