Zugriff auf Docker-Socket innerhalb des Containers

Question

Ich versuche einen Container zu erstellen, der über die Docker-Socket-Datei (Hostcomputer - /var/run/docker.sock) auf die Remote-API des Host-Docker zugreifen kann.

Die Antwort here schlägt vor, Anforderungen an den Socket zu übertragen. Wie würde ich das machen?

Answer 1

Ich fand es heraus. Sie können einfach die die Socket-Datei durch das Volumen Argument übergeben

docker run -v /var/run/docker.sock:/container/path/docker.sock 

Wie @zarathustra weist darauf hin, dies jedoch nicht die beste Idee sein kann. Siehe: https://www.lvh.io/posts/dont-expose-the-docker-socket-not-even-to-a-container.html

Answer 2

Wenn man beabsichtigt, Docker aus einem Container zu verwenden, sollte er die Auswirkungen auf die Sicherheit klar verstehen.

Zugriff auf Docker aus Behälter ist einfach:

1. Verwenden Sie das docker offizielle Bild oder installieren Docker im Inneren des Behälters. Oder können Sie Archiv mit Docker Client binären herunterladen, wie beschrieben here
2. Expose Docker Unix-Socket vom Host zum Behälter

, deshalb,

docker run -v /var/run/docker.sock:/var/run/docker.sock \ 
     -ti docker 

sollte es tun.

Alternativ können Sie in den Behälter freizulegen und verwenden Docker REST API

UPD: Ehemalige Version dieser Antwort (basierend auf früheren Version von jpetazzo post) empfohlen, den Behälter der Docker binäre von dem Host zu binden Montage. Dies ist nicht mehr zuverlässig, da die Docker Engine nicht mehr als (fast) statische Bibliotheken vertrieben wird.

Überlegungen:

1. Alle Host-Container zu Container zugänglich sein wird, so dass er sie stoppen kann, löschen, laufen alle Befehle wie jeder Benutzer innerhalb der obersten Ebene Docker-Container.
2. Alle erstellten Container werden in einem Top-Level-Docker erstellt.
3. Natürlich sollten Sie verstehen, dass, wenn Container Zugriff auf den Docker-Daemon des Hosts hat, dieser einen privilegierten Zugriff auf das gesamte Host-System hat. Je nach Behälter und System (AppArmor) Konfiguration kann es weniger sein oder gefährlicher
4. Andere Warnungen hier dont-expose-the-docker-socket

Andere Ansätze wie Aussetzen /var/lib/docker zu Containern sind wahrscheinlich zur Beschädigung von Daten verursachen. Weitere Informationen finden Sie unter do-not-use-docker-in-docker-for-ci.

Hinweis für Benutzer von offiziellen Jenkins CI Container

In diesem Container (und wahrscheinlich auch in vielen anderen) jenkins läuft Prozess als Nicht-Root-Benutzer. Aus diesem Grund hat es keine Erlaubnis, mit dem Docker-Socket zu interagieren.So schnell & schmutzige Lösung läuft

docker exec -u root ${NAME} /bin/chmod -v a+s $(which docker) 

nach Container zu starten. Dies ermöglicht allen Benutzern im Container, docker binary mit root-Berechtigungen auszuführen. Besserer Ansatz wäre, docker binär über passwordless sudo laufen zu lassen, aber das offizielle Jenkins CI-Image scheint das sudo Subsystem zu vermissen.

Answer 3

ich auf dieser Seite gestoßen beim Versuch Docker Socket-Aufrufe aus einem Behälter arbeiten zu machen, die als nobody Benutzer ausgeführt wird.

In meinem Fall bekam ich Zugriff verweigert Fehler, wenn my-service versuchen würde, Anrufe an den Docker-Socket zu machen, um verfügbare Container aufzulisten.

Ich endete mit docker-socket-proxy, um den Docker-Socket zu my-service Proxy. Dies ist ein anderer Ansatz, um auf den Docker-Socket innerhalb eines Containers zuzugreifen, also würde ich es teilen.

Ich machte my-service in der Lage, den Docker-Host zu empfangen, mit dem es sprechen sollte, docker-socker-proxy in diesem Fall über die Umgebungsvariable DOCKER_HOST.

Beachten Sie, dass docker-socket-proxy als root Benutzer ausgeführt werden muss, um den Docker-Socket zu my-service Proxy zu ermöglichen.

Beispiel docker-compose.yml:

version: "3.1" 

services: 
    my-service: 
    image: my-service 
    environment: 
     - DOCKER_HOST=tcp://docker-socket-proxy:2375 
    networks: 
     - my-service_my-network 
    docker-socket-proxy: 
    image: tecnativa/docker-socket-proxy 
    environment: 
     - SERVICES=1 
     - TASKS=1 
     - NETWORKS=1 
     - NODES=1 
    volumes: 
    - /var/run/docker.sock:/var/run/docker.sock 
    networks: 
     - my-service_my-network 
    deploy: 
     placement: 
     constraints: [node.role == manager] 

networks: 
    my-network: 
    driver: overlay 

Beachten Sie, dass die oben compose Datei bereit Schwarm (docker stack deploy my-service), aber es sollte auch (docker-compose up -d) in Compose-Modus arbeiten. Das Schöne an diesem Ansatz ist, dass my-service nicht mehr auf einem Schwarm-Manager ausgeführt werden muss.