Remote Zugriff auf docker.sock

[RAWWR]

Moin Leute,

drehe hier bald durch. Ich versuche seit ewigkeiten Remote Access auf die docker.sock zu erhalten.
Seit DSM7 und dem Container Manager läuft der ganze Scheiss aber nicht mehr so, dass ich dieser Anleitung aus der offiziellen Dokumentation folgen könnte :/

was ich erreichen möchte ist, dass ich den docker daemon über TCP erreichen kann mit Port 2375 am ende.


ich hoffe ihr könnt mir hier helfen. ich stehe komplett auf dem Schlauch

 

[plang.pl]

Da brauchen wir schon mehr Infos. Was genau willst du machen?

 

[RAWWR]

Da brauchen wir schon mehr Infos. Was genau willst du machen?

Moin Plang.


Aaaalso: Ich habe hier zwei Geräte in meinem Netzwerk. Ne Synology und einen Raspberry.
Auf dem Raspberry läuft ua. Uptime Kuma im Docker. Ich möchte nun mit uptime Kuma den Docker vom Synology monitoren.

In den Settings von uptime kuma wird da nach einer url zum remote docker daemon gefragt.


Das ist der ganze Hintergrund warum ich hier am fummeln bin

----


Kurze Info was ich zuletzt getan habe (leider erfolglos)

die dockerd.json editiert und durch folgenden inhalt ersetzt
{ "data-root":"/var/packages/ContainerManager/var/docker", "log-driver":"db", "registry-mirrors":[], "storage-driver":"btrfs" "hosts" : [ "tcp://192.168.178.200:2375", "unix:///var/run/docker.sock" ], "registry-mirrors" : [] }

 

[plang.pl]

Oh leck. Da kann ich leider nix zu sagen. Aber "/var/packages/ContainerManager/var/docker" hört sich irgendwie falsch an

 

[RAWWR]

ne das passt schon. der Teil ist noch der originale inhalt vom file. Ich hab lediglich die letzten beiden zeilen ergänzt

 

[alexhell]

Ich kann dir da nicht direkt helfen, ich hatte das kurz bei DSM6 auch so eingerichtet. Habe es dann allerdings schnell wieder entfernt, weil dann hat eigentlich jeder im Netzwerk root Zugriff auf deine NAS. Über den Sock kann jedes Image erstellt werden und man könnte einfach Volume1 Mappen und hat Zugriff auf alles. Man kann nämlich als User auch 0:0 mitgeben beim Container.

 

[haydibe]

WARNUNG: der docker socket sollte NIEMALS direkt aus dem Internet erreichbar sein, wenn keine zertifikatsbasierte Authentifizierung dafür aktiviert ist, da ihn sonst JEDER der in erreichen kann auch uneingeschränkt nutzen kann. Wie er in diesem Fall abgesichert werden muss ist hier zu sehen: https://docs.docker.com/engine/security/protect-access/#:~:text=Use TLS (HTTPS) to protect,to a trusted CA certificate.

Es gibt einen Grund, warum mit docker context ein Weg eingeführt wurde, der erlaubt über ssh auf einen remote Socket zuzugreifen.

Die Datei /var/packages/ContainerManager/etc/dockerd.json entspricht /etc/docker/deamon.json von normalen Linux Systemen. Eigentlich sieht das tcp-Binding gut aus. Wie sieht es den in der Ausgabe von docker info aus?

update: deine dockerd.json ist kein valides json. Es fehlt ein Komma am Ende der "storage-driver" Zeile.

 

[RAWWR]

ah super. Ich hab es gestern wieder rückgängig gemacht weil der containermanager als defekt deklariert wurde ich probier es gleich nochmal.

Wegen der sicherheitsgeschichte bin ich schon im Bilde. Das wird dann der nächste Schritt mich da bisschen einzulesen wie man das umgehen kann.


Ich hab zb gesehen das es einen Docker-socket-Proxy Container gibt als Docker Image… der hat allerdings auch 0 funktioniert weil die ganzen kack Pfade nicht korrekt waren

 

[haydibe]

Was funktioniert den bei Tecnativa/docker-socket-proxy nicht?

Der docker.sock ist nichts anderes als ein Http-Rest-Enpdunkt der über einen Unix-Domainsocket angesprochen wird. Der docker-socket-proxy arbeitet einfach nur als Reverse Proxy davor und filtert API-Endpunkt-Pfade die nicht erlaubt werden sollen. Das ist kein Hexenwerk.

Wenn Synology seine Docker so verbogen hätte, dass die Docker-API plötzlich andere Pfade hätten, dann würde auch Portainer nicht mehr damit zusammenarbeiten... ..

 

[RAWWR]

Moin


damit hab ich es tatsächlich zunächst probiert und im Containerlog wirft er mir ständig folgenden error vor die Füsse:

[WARNING] Can't open server state file '/var/lib/haproxy/server-state': No such file or directory Proxy dockerbackend started. Proxy dockerfrontend started. [NOTICE] 260/171530 (1) : New worker #1 (7) forked

das passiert allerdings auch nur, wenn ich "privileged" auf true setze (was in der Anleitung so gefordert ist).


mit Uptimekuma vom Pi kann ich mich damit leider immer noch nicht auf den synology docker verbinden

 

[haydibe]

WARNING!=ERROR

Lass mich raten, Du hast erst gar nicht versucht, ob es funktioniert, sondern hast Dich vom WARNING direkt abschrecken lassen.
Wenn jeder das tun würde, dann würde vermutlich kaum irgendwo eine Software laufen... ein WARNING kann auf ein Problem hinweisen, muss es aber nicht zwingend.

 

[haydibe]

Ich kann nicht feststellen, dass da etwas - trotz Warnung - nicht funktionieren würde:

compose.yml:

version: '2.4'

services:
  docker-proxy:
    image: tecnativa/docker-socket-proxy
    privileged: true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    #environment:
    # CONTAINERS: 1

  docker-cli:
    image: docker:cli
    tty: true
    environment:
      DOCKER_HOST: tcp://docker-proxy

Test:

me@dsm:/volume1/docker/test-dockerproxy$ docker-compose up -d
[+] Running 2/2
 ⠿ Container test-dockerproxy-docker-cli-1    Started                                                                                         0.7s
 ⠿ Container test-dockerproxy-docker-proxy-1  Started                                                                                         0.8s
me@dsm:/volume1/docker/test-dockerproxy$ docker-compose exec docker-cli sh
/ # docker ps
Error response from daemon: <html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>

Dann das # bei beiden auskommentierten Zeilen in der compose.yml entfernen..

me@dsm:/volume1/docker/test-dockerproxy$ docker-compose up -d
[+] Running 2/2
 ⠿ Container test-dockerproxy-docker-proxy-1  Started                                                                                        11.6s
 ⠿ Container test-dockerproxy-docker-cli-1    Started                                                                                        11.5s
me@dsm:/volume1/docker/test-dockerproxy$ docker-compose exec docker-cli sh
/ # docker ps
CONTAINER ID   IMAGE                           COMMAND                  CREATED          STATUS         PORTS      NAMES
...
3778aae807a3   docker:cli                      "docker-entrypoint.s…"   8 seconds ago    Up 7 seconds              test-dockerproxy-docker-cli-1
...
66c153618a2b   tecnativa/docker-socket-proxy   "/docker-entrypoint.…"   18 seconds ago   Up 7 seconds   2375/tcp   test-dockerproxy-docker-proxy-1
...

Fazit: ich kann nicht nachvollziehen das da etwas nicht funktionieren würde.

 

[RAWWR]

doch ich hab das wirklich ewig oft probiert
allerdings hatte ich den "docker-cli" part nicht im stack drin.


wenn ich nun mit exec in den container gehe und dort docker ps eingebe erhalte ich auch die gleiche ausgabe wie du.


aaaaaaaber wenn ich in uptimekuma auf dem raspberry system nun den remote docker konfigurieren möchte, erhalte ich trotzdem die fehlermeldung, dass die verbindung nicht aufgebaut werden konnte. Egal ob ich es mit tcp://synologyip:2375 oder http://synologyip:2375 probiere.

:'D

 

[RAWWR]

oooookay kurzes update.


Ich hab keine Ahnung was genau ich hier gemacht habe, aber wenn ich den ganzen krempel in mein macvlan werfe klappt es auf einmal.


version: '2.4' services: docker-proxy: networks: default: ipv4_address: 192.168.178.69 container_name: dockerproxy image: tecnativa/docker-socket-proxy privileged: true volumes: - /var/run/docker.sock:/var/run/docker.sock environment: CONTAINERS: 1 networks: default: name: mvl-synology-network external: true


ob das jetzt cool is oder nicht..... ich weiss es nicht :'D

 

[haydibe]

allerdings hatte ich den "docker-cli" part nicht im stack drin.

Der war ja auch nur zum Demonstrieren da, damit ich einen Konsumenten habe, der über ein Container-Netzwerk auf den proxy-socket zugreift.

Du wirst auch noch mehr API-Endpunkte aktivieren wollen. Ich hatte jetzt nur als Beispiel CONTAINERS aktiviert. Die anderen Endpunkte aktiviert man, analog zu dem wie ich CONTAINERS aktiviert hatte:

Access revoked by default​

Security-critical​

These API sections are considered security-critical, and thus access is revoked by default. Maximum caution when enabling these.

• AUTH
• SECRETS
• POST: When disabled, only GET and HEAD operations are allowed, meaning any section of the API is read-only.

Not always needed​

You will possibly need to grant access to some of these API sections, which are not so extremely critical but can expose some information that your service does not need.

• BUILD
• COMMIT
• CONFIGS
• CONTAINERS
• DISTRIBUTION
• EXEC
• IMAGES
• INFO
• NETWORKS
• NODES
• PLUGINS
• SERVICES
• SESSION
• SWARM
• SYSTEM
• TASKS
• VOLUMES