Code Monkey home page Code Monkey logo

docker-socket-proxy's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

docker-socket-proxy's Issues

Performance degradation

Hi,

I’m trying to use your image on with my containers but I see a performance degradation compared to using /var/run/docker.sock. For example I'm using Dozzle, a Realtime log viewer for docker containers and if connected
with DOCKER_HOST=tcp://..., it's operation is very slow while using about 25 containers in my setup (home automation and "off-the-could" stuff, Home Assistant, Mosquitto, bitwarden_rs, Emby, etc.). I get the same performance drop from Traefik too, I'm using Dozzle here since it is easy to replicate the issue, no volumes, variables or complex settings.

I tried to debug this with a clean setup on a blank Debian VM with only 3 containers, docker-socket-proxy and two instances of Dozzle, one connected to /var/run/docker.sock and the other one to docker-socket-proxy. I can see the differences while accessing the services pages in my browser. Just by opening the 2 pages side by side and hit refresh in the browser. The instance connected to docker-socket-proxy will be refreshed much slowly than the other one. It is worst on my real system where it takes few seconds to refresh while it is almost instantly refreshed while connected to /var/run/docker.sock. It seems that more containers in the stack, slower the accesses to the Docker socket are.

Is a performance degradation is expected using docker-socket-proxy?

Here is my test docker-compose:

version: "3.8"

networks:
  socket_proxy:
    name: socket_proxy

services:
  socketproxy:
    container_name: socketproxy
    image: tecnativa/docker-socket-proxy:latest
    privileged: true
    environment:
      CONTAINERS: 1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - socket_proxy

  dozzle:
    container_name: dozzle
    image: amir20/dozzle:latest
    #environment:
    #  DOCKER_HOST: tcp://socketproxy:2375
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - socket_proxy
    ports:
      - 8080:8080/tcp
    depends_on:
      - socketproxy

  dozzle2:
    container_name: dozzle2
    image: amir20/dozzle:latest
    environment:
      DOCKER_HOST: tcp://socketproxy:2375
    #volumes:
    #  - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - socket_proxy
    ports:
      - 8081:8080/tcp
    depends_on:
      - socketproxy

Any ideas?

Thanks!

Recurrent logs from Traefik "Provider connection error unexpected EOF"

Hi, we are using docker-socket-proxy with Traefik to protect our docker environment.
In traefik v2.0 logs there are many error logs like these :

time="2019-09-30T14:10:37+02:00" level=error msg="Provider connection error unexpected EOF, retrying in 263.019463ms" providerName=docker
time="2019-09-30T14:20:38+02:00" level=error msg="Provider connection error unexpected EOF, retrying in 372.070307ms" providerName=docker
time="2019-09-30T14:30:38+02:00" level=error msg="Provider connection error unexpected EOF, retrying in 726.287014ms" providerName=docker

the docker-socket-proxy configuration is the minimum

 - CONTAINERS=1

Do you think theses errors appear because docker-socket-proxy is compatible with Docker API version 1.37 and we are using version 1.40?

Another question, does docker-socket-proxy is still maintained?

Thanks you.

export DOCKER_HOST=tcp://localhost

Hi

Sorry for noob question.

But what does this command do:
$ export DOCKER_HOST=tcp://localhost

What will that change on my system and how could i revert the change if required.

I'm always very reluctant to change things directly on my system and I try to keep everything in docker.

I am wondered that the command above will stop me from using docker and may interfere with the scripts that are running because of this paragraph in the wiki

You cannot see running containers:

$ docker container ls
Error response from daemon: <html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.

Currently I can run the docker command, and I'm worried that if I use that export command I will loose access to docker.

Thanks

PS: Sorry for probably idiotic question.

Latest version doesn't start on arm32v7 (raspberry pi 4)

After pulling the latest version, the container logs become

standard_init_linux.go:219: exec user process caused: exec format error
standard_init_linux.go:219: exec user process caused: exec format error
standard_init_linux.go:219: exec user process caused: exec format error
standard_init_linux.go:219: exec user process caused: exec format error
standard_init_linux.go:219: exec user process caused: exec format error
standard_init_linux.go:219: exec user process caused: exec format error
standard_init_linux.go:219: exec user process caused: exec format error
standard_init_linux.go:219: exec user process caused: exec format error
standard_init_linux.go:219: exec user process caused: exec format error

Current fix: ignore latest version by specifying in docker-compose file

image: tecnativa/docker-socket-proxy:arm32v7

instead of

image: tecnativa/docker-socket-proxy

Would you either release an update for arm32v7, or update the tags please ? :)

Multi-arch builds

It would be great to have multi-arch builds for this as well for use on Raspberry Pi and other systems.

I see you use a script to do the builds already, so it would not be too much to change over.

Since haproxy already supports multi-arch, you can use a build arg to set the source repo. I'm not sure how you do builds today, but I can help if you'd like.

Secure config not working in swarm mode with userns-remap

Hi all,

I have been trying for the last 2 weeks to find the perfect security config to run docker swarm on production and I can't manage to find it. I am trying to follow the CIS checklist (https://github.com/docker/docker-bench-security) but I have the following errors when I use the docker-socket-proxy :

error in docker-socket-proxy

10.0.4.4:43234 [09/Sep/2021:09:52:34.244] dockerfrontend dockerbackend/dockersocket 0/0/-1/-1/0 503 213 - - SC-- 1/1/0/0/3 0/0 "GET /v1.24/version HTTP/1.1"
10.0.4.4:43236 [09/Sep/2021:09:52:36.154] dockerfrontend dockerbackend/dockersocket 0/0/-1/-1/0 503 213 - - SC-- 1/1/0/0/3 0/0 "GET /v1.24/version HTTP/1.1"
10.0.4.4:43238 [09/Sep/2021:09:52:40.870] dockerfrontend dockerbackend/dockersocket 0/0/-1/-1/0 503 213 - - SC-- 1/1/0/0/3 0/0 "GET /v1.24/version HTTP/1.1"

error in traefik

time="2021-09-09T08:56:52Z" level=error msg="Failed to retrieve information of the docker client and server host: Error response from daemon: <html><body><h1>503 Service Unavailable</h1>\nNo server is available to handle this request.\n</body></html>" providerName=docker
time="2021-09-09T08:56:52Z" level=error msg="Provider connection error Error response from daemon: <html><body><h1>503 Service Unavailable</h1>\nNo server is available to handle this request.\n</body></html>, retrying in 15.355607007s" providerName=docker

Here is my config
I have created the following network

sudo docker network create --driver overlay --opt encrypted web-servers 

/etc/docker/daemon.json

{
  "icc": false, #I don't want automatic network discovery of the containers 
  "live-restore": false, #not used in swarm mode
  "userland-proxy": false, #(I have tried with true and it doesn't work either)
  "iptables": true,
  "no-new-privileges": true, #I don't want privileged containers
  "log-driver" : "syslog",
  "userns-remap": "default" #I want containers to run as non root users
}

docker-compose-traefik.yaml

version: "3.3"

services:
  traefik:
    image: "traefik:v2.4"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      # traefik static configuration
      - ./traefik-config.yaml:/etc/traefik/traefik.yml:ro
      # custom folder with SSL certs
      - ./domainssl:/etc/traefik/domainssl:ro
     # custom folder with dynamic configuration
      - ./custom:/etc/traefik/custom:ro
       # ssl volumes to store acme.json
      - certs:/letsencrypt
    networks:
      - web-servers
      - socket-proxy
    deploy:
      placement:
        constraints:
          - node.role == manager
      labels:
        - "traefik.enable=true"
        - "traefik.docker.network=web-servers"
        - "traefik.http.routers.dashboard.rule=Host(`XXXXXXXX`)"
        - "traefik.http.routers.dashboard.entrypoints=websecure"
        - "traefik.http.routers.dashboard.service=api@internal"
        - "traefik.http.routers.dashboard.middlewares=traefik-auth"
        - "traefik.http.middlewares.traefik-auth.basicauth.users=XXXX:XXXXXXX"
        - "traefik.http.services.dashboard.loadbalancer.server.port=8080"

  socket-proxy:
    image: tecnativa/docker-socket-proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      CONTAINERS: 1
      SERVICES: 1
      NODES: 1
      NETWORKS: 1
      TASKS: 1
      VERSION: 1
    networks:
      - socket-proxy
    deploy:
      placement:
        constraints:
          - node.role == manager
networks:
  web-servers:
    external: true
  socket-proxy:
    internal: true

volumes:
  certs:

traefik-config.yaml

entryPoints:
  web:
    address: :80
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https

  websecure:
    address: :443
    http:
      tls:
        certResolver: myresolver
      middlewares:
      - SecHeaders@file

accessLog: {}

api:
  dashboard: true
  insecure: true

providers:
  docker:
    exposedByDefault: false
    endpoint: "tcp://socket-proxy:2375"
    swarmMode: true
    network: "web-servers"
    watch: true

  file:
    directory: /etc/traefik/custom/
    watch: true

certificatesResolvers:
  myresolver:
    acme:
      email: "XXXXX"
      storage: "/letsencrypt/acme.json"
      tlsChallenge: {}

The problem is coming from the userns-remap option in the daemon config. When I switch if off (reinstall without), it is working but both containers have root permissions... Is there a way to make it work with the userns-remap option on?

Many thanks in advance for your help

Non-root user?

Hi, I tried building an image based on yours which would run as a non-priv user but breaks Traefik.

Traefik log

time="2019-11-30T11:40:00Z" level=error msg="Failed to retrieve information of the docker client and server host: Error response from daemon: <html><body><h1>503 Service Unavailable</h1>\nNo server is available to handle this request.\n</body></html>" providerName=docker
time="2019-11-30T11:40:00Z" level=error msg="Provider connection error Error response from daemon: <html><body><h1>503 Service Unavailable</h1>\nNo server is available to handle this request.\n</body></html>, retrying in 462.318748ms" providerName=docker

Dockerfile

FROM tecnativa/docker-socket-proxy

# Create demyx user
RUN set -ex; \
    addgroup -g 1000 -S demyx; \
    adduser -u 1000 -D -S -G demyx demyx

# Finalize
RUN set -ex; \
    touch /tmp/server-state; \
    sed -i "s|pidfile /run|pidfile /tmp|g" /usr/local/etc/haproxy/haproxy.cfg; \
    sed -i "s|/var/lib/haproxy|/tmp|g" /usr/local/etc/haproxy/haproxy.cfg

USER demyx

Using tecnativa/docker-socket-proxy makes Traefik work but I don't wanna run this container as root with --privileged. Any help is appreciated!

Provide dockerhub tags

Docket swarm does not like the use of the latest tag and might result in various versions running in the swarm.

Please provide tags for every "release".

Error "Docker daemon connection interrupted" after 20 minutes of bringing up containers

Hi,

I was checking your image with the following setup and I am getting the error "Docker daemon connection interrupted" after 20 minutes of bringing up containers, and then it repeats every 10 minutes after that:

image

This is my docker-compose.yml:

version: '3.8'
services:
  socket-proxy:
    image: tecnativa/docker-socket-proxy
    ports:
      - "127.0.0.1:2375:2375"
    # privileged: true # true for VM, false for unprivileged LXC container
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      LOG_LEVEL: debug # debug,info,notice,warning,err,crit,alert,emerg
      # Flags: 0 to revoke or 1 to grant access
      ## Granted by Default
      EVENTS: 1 # nginx-proxy
      PING: 1 # nginx-proxy
      VERSION: 1
      ## Revoked by Default
      # Security critical
      AUTH: 1
      SECRETS: 1
      POST: 1
      # Not always needed
      BUILD: 1
      COMMIT: 1
      CONFIGS: 1
      CONTAINERS: 1
      DISTRIBUTION: 1
      EXEC: 1
      IMAGES: 1
      INFO: 1
      NETWORKS: 1
      NODES: 1
      PLUGINS: 1
      SERVICES: 1
      SESSION: 1
      SWARM: 1
      SYSTEM: 1
      TASKS: 1
      VOLUMES: 1
    networks:
      - proxy

  nginx-proxy:
    image: jwilder/nginx-proxy:1.3
    ports:
      - 80:80
      - 443:443
    volumes:
      #- /var/run/docker.sock:/tmp/docker.sock:ro
      - ssl:/etc/nginx/certs
      - vhost:/etc/nginx/vhost.d
      - html:/usr/share/nginx/html
    environment:
      DOCKER_HOST: "tcp://socket-proxy:2375"
    labels:
      com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy: ""
    networks:
      - proxy
      - edge
      - frontend
    depends_on:
      - socket-proxy

  acme-companion:
    image: nginxproxy/acme-companion:2.2
    volumes:
      #- /var/run/docker.sock:/var/run/docker.sock:ro
      - acme:/etc/acme.sh
      - ssl:/etc/nginx/certs
      - vhost:/etc/nginx/vhost.d
      - html:/usr/share/nginx/html
    environment:
      DOCKER_HOST: "tcp://socket-proxy:2375"
    networks:
      - proxy
      - edge
      - frontend
    depends_on:
      - nginx-proxy

  apache:
    image: bitnami/apache:2.4
    volumes:
      # Web files
      - ./test:/app
    environment:
      VIRTUAL_HOST: fulano.com
      VIRTUAL_PORT: 8080
    networks:
      - frontend
    depends_on:
      - nginx-proxy

volumes:
  ssl:
  vhost:
  html:
  acme:

networks:
  edge:
  frontend:
  proxy:

This is my docker version:

$ docker version
Client:
 Version:           20.10.21
 API version:       1.41
 Go version:        go1.18.1
 Git commit:        20.10.21-0ubuntu1~20.04.2
 Built:             Thu Apr 27 05:56:19 2023
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.21
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.1
  Git commit:       20.10.21-0ubuntu1~20.04.2
  Built:            Thu Apr 27 05:37:01 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.12-0ubuntu1~20.04.1
  GitCommit:        
 runc:
  Version:          1.1.4-0ubuntu1~20.04.3
  GitCommit:        
 docker-init:
  Version:          0.19.0
  GitCommit:        

This is what I get on the logs of the nginx-proxy (also happens on the acme-companion one):

dockergen.1 | 2023/06/11 14:25:25 Docker daemon connection interrupted

And this on the systemd docker.service log:

jun 11 16:25:25 prt2 1b5ccb10ab23[5650]: dockergen.1 | 2023/06/11 14:25:25 Docker daemon connection interrupted
jun 11 16:25:25 prt2 dockerd[5650]: time="2023-06-11T16:25:25.455961717+02:00" level=debug msg="Client context cancelled, stop sending events"
jun 11 16:25:25 prt2 b85512b08cc9[5650]: 192.168.144.5:40022 [11/Jun/2023:14:15:25.454] dockerfrontend dockerbackend/dockersocket 0/0/0/0/600001 200 230 - - sD-- 9/9/8/8/0 0/0 "GET /events? HTTP/1.1"
jun 11 16:25:25 prt2 ba6f37369766[5650]: 2023/06/11 14:25:25 Docker daemon connection interrupted
jun 11 16:25:35 prt2 1b5ccb10ab23[5650]: dockergen.1 | 2023/06/11 14:25:35 Watching docker events

What I have tried without luck:

  • Enable the privileged mode in the socket-proxy container as my system has an app_armour profile enabled for Docker.
  • Enable/allow all API calls (as you can see on the compose file above).

Maybe it has something to do with the api version (unsupported)?

Thanks in advance.

macvlan?

Hello I have traefik under macvlan and in same docker-coppose the socket proxy.

How can I make traefik speak to the proxy? Right now it tries dockersocket which cannot be found

Thanks!
23-08-27T10:33:16Z" level=error msg="Failed to retrieve information of the docker client and server host: error during connect: Get "http://dockersocket:2375/v1.24/version\": dial tcp: lookup dockersocket on 127.0.0.11:53: no such host" providerName=docker

HAProxy

When I run the image, in the logs I get the below:
Can't open server state file '/var/lib/haproxy/server-state': No such file or directory

I checked the container and did not find that folder as well

/ # ls /var/lib/
apk     misc    udhcpd

Not sure if this has a direct impact on portainer not working using the socket-proxy, as well as the HomeAssistant container showing that the TCP is disconnected

DockerError(900, 'Cannot connect to Docker Engine via tcp://172.18.0.199:2375 [Server disconnected]')

my compose for the socket / portianer / homeassistant are as following:

  socket:
    container_name: socketproxy
    restart: $ALWAYS_ON_POLICY
    environment:
        PUID: $PUID
        PGID: $PGID
        LOG_LEVEL: err # debug,info,notice,warning,err,crit,alert,emerg
        ## Variables match the URL prefix (i.e. AUTH blocks access to /auth/* parts of the API, etc.).
        # 0 to revoke access.
        # 1 to grant access.
        ## Granted by Default
        EVENTS: 1
        PING: 1
        VERSION: 1
        ## Revoked by Default
        # Security critical
        AUTH: 0
        SECRETS: 0
        POST: 1 # Watchtower
        # Not always needed
        BUILD: 1
        COMMIT: 1
        CONFIGS: 1 #0
        CONTAINERS: 1 # Traefik, portainer, etc.
        DISTRIBUTION: 1 #0
        EXEC: 1 #0
        IMAGES: 1 # Portainer
        INFO: 1 # Portainer
        NETWORKS: 1 # Portainer
        NODES: 1 #0
        PLUGINS: 1 #0
        SERVICES: 1 # Portainer
        SESSION: 1 #0
        SWARM: 1 #0
        SYSTEM: 1
        TASKS: 1 # Portainer
        VOLUMES: 1 # Portainer
    volumes:
        - /var/run/docker.sock:/var/run/docker.sock
    ports:
        #- 127.0.0.1:2375:2375 # Port 2375 should only ever get exposed to the internal network. When possible use this line.
    # Use the next line instead, as I want portainer to manage multiple docker endpoints within my home network.
        - 2375:2375
    privileged: true
    image: 'tecnativa/docker-socket-proxy:latest'
  portainer-ce:
    container_name: portainer-ce
    restart: $ALWAYS_ON_POLICY
    command: -H $DOCKER_HOST
    environment:
      DOCKER_HOST: $DOCKER_HOST
    volumes:
      - $PERSIST/portainer-ce:/data
    ports:
      - 8000:8000/tcp
      - 9000:9000/tcp
      - 9443:9443/tcp
    image: 'portainer/portainer-ce'
  homeassistant:
    container_name: homeassistant
    restart: $ALWAYS_ON_POLICY
    privileged: true
    environment:
      - DOCKER_HOST=$SOCKET
      - PUID=$PUID
      - PGID=$PGID
      - TZ=$TZ
    volumes:
      - $LOCAL_TIME:/etc/localtime:ro
      - $PERSIST/homeassistant:/config:rw
    ports:
      - 8123:8123
    working_dir: /config
    depends_on:
      - mariadb
    image: 'ghcr.io/home-assistant/home-assistant:stable'

Error accessing proxy from traefik

I'm using this with traefik and it works like a charm.

...Except when it doesn't. For example, when I must update services, and then restart traefik. Then traefik restarts without error, and the container becomes "healthy". But requests to services time out.

I thought it was a traefik problem. Then I checked the logs, and every time I have this issue I see something like this:

time="2023-07-17T07:44:45+03:00" level=error msg="Provider connection error error during connect: Get "http://tecnativa:2375/v1.24/version\": dial tcp: lookup tecnativa on 127.0.0.11:53: no
such host, retrying in 9.503388201s" providerName=docker

The "no such host" part is incorrect, because the tecnativa container is working, and reported as "healthy". I wonder what that v1.24 is?

The only solution is to restart both traefik and tecnativa (and sometimes other services which are served by traefik!)

I am using the most recent official tecnativa release 0.1.1. And docker 24.0.4 on debian.

Any ideas?

Unable start/stop/restart/remove container from remote host via Portainer

Hi, I love this project congratulations...

From a remote host I would like to be able to start/stop/restart/remove the containers via Portainer but I get the following error

Failure
Request failed with status code 403

This is my docker run

docker container run \
    -d --privileged \
    --name dockerproxy \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -p 0.0.0.0:2375:2375 \
    -e BUILD=1 \
    -e COMMIT=1 \
    -e CONFIGS=1 \
    -e CONTAINERS=1 \
    -e DISTRIBUTION=1 \
    -e EXEC=1 \
    -e GRPC=1 \
    -e IMAGES=1 \
    -e INFO=1 \
    -e NETWORKS=1 \
    -e NODES=1 \
    -e PLUGINS=1 \
    -e SERVICES=1 \
    -e SESSION=1 \
    -e SWARM=1 \
    -e SYSTEM=1 \
    -e TASKS=1 \
    -e VOLUMES=1 \
    tecnativa/docker-socket-proxy

Thanks in advance
PC

Startup warning

I use tecnativa/docker-socket-proxy:arm32v7 on my Pi4 and get the following startup output:

image

Is the warning something I need to worry about?

Events timeout

Hello!
We are using this to watch Docker events from inside a container, but the connection is closed every 10 minutes 😃
A longer timeout should be at least configurable for the events endpoint.

Docs on Swarm need to point out it must be deployed on manager nodes

In Docker Swarm, the docker socket only exists on manager nodes, so this was failing sporadically for me without much explanation until I realized it was whenever the proxy was deployed to a worker node. Here are the constraints required in docker compose format:

 deploy:
      mode: global
      placement:
        constraints:
          - node.role == manager

503 with docker-desktop on Mac

With docker-desktop 4.20.1 on Mac, the following crashes with a HTTP 503 error:

# get the location of the currently active docker socket, will be something like $HOME/.docker/run/docker.sock
#
socket="$(docker context ls --format '{{.Current}}\t{{.DockerEndpoint}}' | awk '$1 == "true" { print $2 }')"
socket="${socket#unix://}"

# run the socket proxy
#
docker run -p 2375:2375 -v "${socket}:/var/run/docker.sock:ro" -d --rm tecnativa/docker-socket-proxy

# make a call to the proxy: this crashes
#
DOCKER_HOST=tcp://127.0.0.1:2375 docker ps

Hard-coding socket=/var/run/docker.sock works fine, but shouldn't there be a way to respect the socket location provided by the docker context?

Other approaches I tried which didn't work:

  • Adding --privileged to the docker run command: same crash with a 503
  • Adding --user $UID:$GID to the docker run command: container fails to start with error "Cannot create pidfile /run/haproxy.pid"

ability to modify frontend bind

Hello, it will be great to allow users to modify the frontend.bind parameter to bind on UNIX sockets and ports other than 2375.

Use case: provide untrusted application access to the docker socket. The untrusted app can work only via a UNIX socket.

Proposed solution: #68

Built an image for ARM

Hi!

I wanted to use this image on my Raspberry Pi so I cloned the repository and built an image for ARM. How could I share it so it's available on Docker Hub and/or this repository? I noticed there's already a discussion about supporting multi-architecture builds (cf. #17) but I only see amd64 on Docker Hub.

Thanks in advance!

tecnativa_docker-socket-proxy Tags - Docker Hub -

Add example non-default env variables

It would be useful to me to see an example of one way the proxy could be configured with env variables.

My understanding is that to explicitly grant the proxy access to SECRETS, I would add the line -e SECRETS=1 to the Docker run command, or - SECRETS=1 to the environment block of my docker-compose.yml.

The system is pretty simple and intuitive, but I think basic security practices like this should be as approachable and accessible as possible.

An example docker-compose.yml file would also be useful, perhaps with commented modification env variables.

logging is broken

haproxy-systemd-wrapper: executing /usr/local/sbin/haproxy -p /run/haproxy.pid -f /usr/local/etc/haproxy/haproxy.cfg -Ds
[WARNING] 222/173808 (6) : Can't open server state file '/var/lib/haproxy/server-state': No such file or directory
[ALERT] 222/173808 (6) : sendmsg logger #1 failed: No such file or directory (errno=2)
[ALERT] 222/173808 (6) : sendmsg logger #1 failed: No such file or directory (errno=2)

proxy as volume with glances

Hello, I want to run glances using your proxy. The only option to set the proxy is via volumes.

volumes: 
   - "tcp://socket-proxy:2375/:/var/run/docker.sock:ro"

doesn't work. how can I do that?

portainer & portainer-agent swarm mode help

Hi there,

I am trying to set it up within the swarm but its a bit confusing on what I exactly need to change there or how to set it up.
Do u have any Informations about this?

  socket-proxy:
    container_name: socket-proxy
    image: tecnativa/docker-socket-proxy
    restart: always
    networks:
      socket_proxy:
        ipv4_address: xyz
    privileged: true
    ports:
      - "2375:2375"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
    environment:
      - LOG_LEVEL=debug # debug,info,notice,warning,err,crit,alert,emerg
      ## Variables match the URL prefix (i.e. AUTH blocks access to /auth/* parts of the API, etc.).
      # 0 to revoke access.
      # 1 to grant access.
      ## Granted by Default
      - EVENTS=1
      - PING=1
      - VERSION=1
      ## Revoked by Default
      # Security critical
      - AUTH=0
      - SECRETS=0
      - POST=0 # Ouroboros auf 1 falls benötigt
      # Not always needed
      - BUILD=0
      - COMMIT=0
      - CONFIGS=0
      - CONTAINERS=1 # Traefik, portainer, etc.
      - DISTRIBUTION=0
      - EXEC=0
      - IMAGES=1 # Portainer
      - INFO=1 # Portainer
      - NETWORKS=1 # Portainer
      - NODES=0
      - PLUGINS=0
      - SERVICES=1 # Portainer
      - SESSION=0
      - SWARM=1 # Needed auf 1?
      - SYSTEM=0
      - TASKS=1 # Portaienr
      - VOLUMES=1 # Portainer
    deploy:
      restart_policy:
        condition: on-failure
      placement:
        constraints: [node.role == manager]

  agent:
    image: portainer/agent
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock # command: -H tcp://socket-proxy:2375 <= needed?
      - /var/lib/docker/volumes:/var/lib/docker/volumes
    networks:
      - agent_network
    deploy:
      mode: global
      placement:
        constraints: [node.platform.os == linux]

  portainer:
    image: portainer/portainer-ce
    command: -H tcp://tasks.agent:9001 --tlsskipverify # // command: -H tcp://socket-proxy:2375 <= needed?
    ports:
      - "9000:9000"
      - "8000:8000"
    environment:
      - TZ=$TZ
      - DOCKER_HOST=socket-proxy:2375
    volumes:
      - portainer_data:/data
    networks:
      - agent_network
      - t2_proxy
      - socket_proxy
    deploy:
      mode: replicated
      replicas: 1
      placement:
        constraints: [node.role == manager]

volumes:
  portainer_data:

Are those changes correct and would the agent work on other nodes?

503 with podman socket

Trying to get this running with the podman socket with the following setup:

  docker-socket-proxy:
    image: tecnativa/docker-socket-proxy
    container_name: docker-socket-proxy
    restart: always
    privileged: true
    environment:
      - SOCKET_PATH=/run/podman/podman.sock
      - CONTAINERS=1
    security_opt:
      - label=disable
    volumes:
      - /run/podman/podman.sock:/run/podman/podman.sock:ro

Seem to be getting a 503 though, not sure why.

HAProxy logs:

10.69.0.155:37856 [27/Feb/2022:07:55:28.777] dockerfrontend dockerbackend/dockersocket 0/0/-1/-1/0 503 213 - - SC-- 1/1/0/0/3 0/0 "GET /containers/baba2851b7771b0603152904c27ac5a354850a10a8414e06fcfa616754e5610b/json HTTP/1.1"
10.69.0.155:37858 [27/Feb/2022:07:55:28.895] dockerfrontend dockerbackend/dockersocket 0/0/-1/-1/0 503 213 - - SC-- 1/1/0/0/3 0/0 "GET /containers/2ef63ee42473922c7e999dd380e81058a212c8e8b67871f61f7645f60958d891/json HTTP/1.1"
10.69.0.155:37862 [27/Feb/2022:07:55:29.013] dockerfrontend dockerbackend/dockersocket 0/0/-1/-1/0 503 213 - - SC-- 1/1/0/0/3 0/0 "GET /containers/2ef63ee42473922c7e999dd380e81058a212c8e8b67871f61f7645f60958d891/json HTTP/1.1"

If I exec into the container and try to access the socket though, it works fine:

/ # curl --unix-socket /var/run/podman/podman.sock docker-socket-proxy:3725/containers/faade8bf2b744d7799623d27ff550da8e257e1aa0142d0b6ab5379481ae07aff/json

{"Id":"faade8bf2b744d7799623d27ff550da8e257e1aa0142d0b6ab5379481ae07aff","Created":"2022-02-20T20:38:48.884569982Z",..........................

Add versioned tags to dockerimage

It would be great to have tags on the docker image so one can automatically detect and upgrade to a new version when one is available. This would be especially interesting when #32 is realized.

Privileged?

Hi,

Thanks for your work.

One question, why does the container need to run as --privileged?

Cheers,
Pierre

restrict to network/docker-compose services

Hi, is it posible that I can only access (throug docker.sock) information of containers/services which are in an spesific network, or better only containers/services which I defined in my docker-compose?

My goal is to host multiple Systems, every System has a docker-compose.yml and I want to use a traefik container in every docker-compose System.

Does not prevent URL encoded API interaction

This proxy is a great idea and very simple. I've started having a look at whether this would suit some of my use-cases, and have found that due to it's blacklist approach there are ways of working around the controls.

If a user submits a request to the API in a non-ascii format, such as URL encoded, the request doesn't match the regex and is thus allowed:

$ curl http://localhost:2375/v1.24/containers/json
<html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>

Submitting the same with the 1 replaced with it's URL encoded format %31 the request is allowed:

$ curl http://localhost:2375/v%31.24/containers/json
[{"Id":"26b2cee8328bd45919fe825073c3754de3abba78992f3970b7f97967d9cad777","Names":["/dockerproxy"],"Image":"tecnativa/docker-socket-proxy","ImageID":"sha256:f546af4b04b12997210dcac107ecd8f3aa6155008d53dadc2a853e5b06ab1fe2","Command":"/docker-entrypoint.sh haproxy -f /usr/local/etc/haproxy/haproxy.cfg","Created":1499066538,"Ports":[{"IP":"127.0.0.1","PrivatePort":2375,"PublicPort":2375,"Type":"tcp"}],"Labels":{"org.label-schema.build-date":"2017-03-31 11:33:22.424874532+00:00","org.label-schema.license":"Apache-2.0","org.label-schema.schema-version":"1.0","org.label-schema.vcs-ref":"0715eb786b603fcd0be319f34efcca6a659f5ae4","org.label-schema.vcs-url":"https://github.com/Tecnativa/docker-tcp-proxy","org.label-schema.vendor":"Tecnativa"},"State":"running","Status":"Up 5 days","HostConfig":{"NetworkMode":"default"},"NetworkSettings":{"Networks":{"bridge":{"IPAMConfig":null,"Links":null,"Aliases":null,"NetworkID":"da0b314d6703f8ff34dbb7c85adaf135676a0aefd783f7fd6169841154f623f3","EndpointID":"dde6a306117204ec3af30d125c469d943c56766ec5683519a75b7b94c230a0eb","Gateway":"172.17.0.1","IPAddress":"172.17.0.2","IPPrefixLen":16,"IPv6Gateway":"","GlobalIPv6Address":"","GlobalIPv6PrefixLen":0,"MacAddress":"02:42:ac:11:00:02"}}},"Mounts":[{"Type":"bind","Source":"/var/run/docker.sock","Destination":"/var/run/docker.sock","Mode":"","RW":true,"Propagation":""}]}]

I think a whitelist approach may be a better way to go - have you had any thoughts about this? Will have a tinker and see if I can get a PR together.

Clean versioning and accountability to avoid supply-chain-attacks

People are using docker-socket-proxy to reduce the risk of having services access the docker socket directly. At the same time they put a lot of trust in the docker-socket-proxy software and containers by giving it almost complete access to the system.

It would be great to have a common versioning on GitHub and Docker Hub to show a little bit more that everything is under control. Currently the last commit on GitHub is from Dec 2022, the last release is from Jan 2021, but there is a new Docker Hub version from July 2023. Are they all the same? What is the difference?

Who is in control of and creates the Docker Hub version?

can't fetch service

hello,
I have this stack on a swarm cluster :

services:
  dockerproxy:
    image: tecnativa/docker-socket-proxy
    privileged: true
    deploy:
      placement:
        constraints:
          - node.role == manager
    environment:
      CONTAINERS: 1
      NETWORKS: 1
      POST: 1
      SERVICES: 1
      SWARM: 1
      TASKS: 1
    networks:
      - docker-socket
    ports:
      - protocol: tcp
        published: 2375
        target: 2375
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

I can access containers:

oliver@fz-manager-1:~$ docker container ls
CONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS               NAMES
9bfaabc7f264        tecnativa/docker-socket-proxy:latest   "/docker-entrypoint.…"   2 minutes ago       Up 2 minutes        2375/tcp            infra_dockerproxy.1.xwzozoorpy29wjgvk2fw04517
f957acd29b76        portainer/agent:latest                 "./agent"                21 hours ago        Up 21 hours                             infra_agent.cvq7fcrp5yym6k4cga6yhkwnj.ww7weeuft3epioahnr3wqjavm

but not services :

oliver@fz-manager-1:~$ docker service ls
Error response from daemon: <html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>

Here is the docker version :

oliver@fz-manager-1:~$ docker version
Client:
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.13.8
 Git commit:        afacb8b7f0
 Built:             Wed Mar 11 23:42:35 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.8
  Git commit:       afacb8b7f0
  Built:            Wed Mar 11 22:48:33 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.3.3-0ubuntu2
  GitCommit:        
 runc:
  Version:          spec: 1.0.1-dev
  GitCommit:        
 docker-init:
  Version:          0.18.0
  GitCommit:        

Possible to apply container label to all containers started through the proxy?

Hey folks, is it possible for the docker-socket-proxy to mutate requests as it proxies them? I'm hoping that I can mutate requests to create containers by adding an additional container label. That way it's easy to query/search for containers on the host that were started via a particular proxy instance.

My use-case is that we have an application that may start/stop docker containers during its normal operation, but we want to be able to detect/mitigate container leaks (this application may forget it started a docker container or it may terminate before cleaning these containers up). I'm hoping that we can run an instance of docker-socker-proxy with a hook that adds a label to all container creations. This would effectively namespace the containers started by our application so they can be monitored programmatically.

Stop containers with Portainer

Hi!

With the following configuration I can't stop containers with Portainer:

environment:
  - LOG_LEVEL=info
  - ALLOW_RESTARTS=1
  # Access granted by default
  - EVENTS=1
  - PING=1
  - VERSION=1
  # Access revoked by default
    # Security-critical
  - AUTH=0
  - SECRETS=0
  - POST=0
    # Not always needed
  - BUILD=0
  - COMMIT=0
  - CONFIGS=0
  - CONTAINERS=1
  - DISTRIBUTION=0
  - EXEC=0
  - GRPC=0
  - IMAGES=1
  - INFO=1
  - NETWORKS=1
  - NODES=0
  - PLUGINS=0
  - SERVICES=1
  - SESSION=0
  - SWARM=0
  - SYSTEM=0
  - TASKS=1
  - VOLUMES=1

I don't know if it is a bug or I am not understanding it correctly. But I think ALLOW_RESTARTS=1 should allow me to do this.

Does anyone know what can happen? Is it necessary to activate POST? If I turn on POST and ALLOW_RESTARTS at the same time, does it only allow "stop, restart and kill" or turn on all POST options?.

Thank you very much.

Seeing a warning when starting the container

docker-socket-proxy  | [WARNING] 017/082756 (1) : Can't open global server state file '/var/lib/haproxy/server-state': No such file or directory     
docker-socket-proxy  | Proxy dockerbackend started.                                                                                                  
docker-socket-proxy  | Proxy dockerfrontend started.                                                                                                 
docker-socket-proxy  | [NOTICE] 017/082756 (1) : New worker #1 (8) forked

everything works I just wanted toreport this.

Large storage utulisation

running as a container i can see it took up to 25GB on space. what is it exactly caching/collecting? reboot didn't cleanup

Add support for /grpc calls

I am trying to run a docker buildx through this proxy, which fails. When running this command, a call to the /grpc api is done, which fails since it's not enabled. I looked at the configuration and it seems that it is not possible to enable yet.

Call:

docker buildx build .

Relevant part of the log:

dockerfrontend dockerfrontend/<NOSRV> 0/-1/-1/-1/0 403 189 - - PR-- 5/5/0/0/0 0/0 "POST /grpc HTTP/1.1"

Other calls like docker run busybox do work.

Update to HAProxy 2?

HAProxy 1.9 looks to be about 1.5 years old. Meanwhile HAProxy 2.2 is noted as being an LTS release, which might be a good base for this container.

I locally updated the image to use haproxy:2.2-alpine and the configuration file didn't produce any errors when tested using this version. Any thoughts about updating to a more recent HAProxy?

Invalid bind address format: port is required

Hi, I had an error message when I export the socket endpoint as described in the documentation
export DOCKER_HOST=tcp://localhost

Traceback (most recent call last):
  File "bin/docker-compose", line 6, in <module>
  File "compose/cli/main.py", line 72, in main
  File "compose/cli/main.py", line 125, in perform_command
  File "compose/cli/command.py", line 76, in project_from_options
  File "compose/cli/command.py", line 142, in get_project
  File "compose/cli/docker_client.py", line 47, in get_client
  File "compose/cli/docker_client.py", line 141, in docker_client
  File "site-packages/docker/context/context.py", line 26, in __init__
  File "site-packages/docker/context/config.py", line 77, in get_context_host
  File "site-packages/docker/utils/utils.py", line 281, in parse_host
docker.errors.DockerException: Invalid bind address format: port is required: tcp://localhost
[12211] Failed to execute script docker-compose

I'm not sure if the documentation should be updated to export the endpoint with the port.
export DOCKER_HOST=tcp://localhost:2375

Plans for next tagged release?

The docs state that the most recent supported API is 1.37.

According to docker's release history, that corresponds to engine 18.05. The release notes for that version show it to have been released on 2018-04-25 (roughly five years ago 😮).

I'm using docker engine 24 and I'm worried of compatibility issues.

I'm using the latest tagged version of tecnativa/docker-socket-proxy:0.1.1 (i.e. "latest"), because we need that for stability and reproducibility (just good sysadmin practice).

I note that there is lots of activity on this repo, but only one tagged release. Any plans to make another release?

[Q] Does a docker socket proxy improve security?

Originally posted at StackExchange and the docker forums.

I am using this docker image and think it's great, so please don't get offended by my question... I'm not trolling, I am very interested in this topic. Also note that this image has very high visibility because major apps (like Traefik) recommend it. So many people would be interested in this question.


It's dangerous to expose the docker socket to a container, as malicious code could break out into the host. There are various ways to avoid this; a simple/popular approach is to use a proxy between the container and the docker daemon, which filters naughty requests. (The most widely used is Tecnativa Docker Socket Proxy.)

But surely that just moves the risk from the operational container (e.g. Traefik or Portainer, which need access to the docker API) to the socket-proxying container (e.g. Tecnativa)? Just as there could be malicious code inside Traefik that would abuse the docker socket, there could be malicious code inside Tecnativa that would abuse the docker socket.

One could even make the argument that it's more sensible to trust Traefik / Portainer (which have huge user bases, and large numbers of developers) to a docker socket proxy. (In other cases, of random never-heard-of container images that wants docker socket access, I'd obviously trust the socket proxy more.)

Is this an example of copy-and-paste-blog-advice, or is there more to it that I don't understand?

Allow environment variable to configure socket path?

I have an interesting use case with balenaOS, which has an idiosyncrasy that prevents this image from working as-is:

  1. Containers gain access to the Docker socket via a galena-specific label:
labels:
  io.balena.features.balena-socket: true
  1. When this label is added, the socket is assigned a specific, non-configurable path: /var/run/balena-engine.sock
  2. balenaOS doesn't allow bind mounts (meaning that we can't expose the socket via /var/run/docker.sock)

This could be remedied by allowing the image's socket path to be overridden by an environment variable.

Pulling image access

How can I allow pulling of an image?.
IMAGES=1 does not allow it. I can list images, but not pull them.

Trying to build docker (23.0.3) image inside gitlab-runner

Hi :)

I'm facing a problem i didn't have before with socket-proxy, here my docker compose stack :

  • a gitlab instance which runs CICD pipelines with alpine gitlab-runner
  • my runners :
    • are on the same network of gitlab and another network for socket proxy
    • don't have access to docker unix socket and it linked to docker instructions with socket proxy on port 2375
    • pull an image of docker:23.0.3-dind-rootless (previously docker:20.10.20-dind-rootless)
  • inside the DIND container, i use docker build
  • docker-socket-proxy service has all environment variables to true value

on 20.10.20 dind version it's alright but on 23.0.3 i have a tricky error message :

$ docker build \ # collapsed multi-line command
WARNING: buildx: git was not found in the system. Current commit information was not captured by the build
ERROR: listing workers for Build: failed to list workers: Unavailable: write tcp 172.31.0.12:35916->172.31.0.11:2375: use of closed network connection
ERROR: Job failed: exit code 1

here are logs of docker-socket-proxy service (i'm surprised that calls have been executed on v1.42 api, and grpc calls are forbidden 403) :

dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 335 - - ---- 1/1/0/0/0 0/0 "HEAD /_ping HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/5/5 200 2557 - - ---- 1/1/0/0/0 0/0 "GET /v1.42/info HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 200 1886 - - ---- 1/1/0/0/0 0/0 "GET /v1.42/images/registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-dcfb4b66/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 1886 - - ---- 1/1/0/0/0 0/0 "GET /v1.42/images/registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-dcfb4b66/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 200 6185 - - ---- 1/1/0/0/0 0/0 "GET /v1.42/images/affineurs/dind:23-build/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/848/858 200 473 - - ---- 1/1/0/0/0 0/0 "POST /v1.42/images/create?fromImage=affineurs%2Fdind&tag=23-build HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/2/2 200 6185 - - ---- 1/1/0/0/0 0/0 "GET /v1.42/images/affineurs/dind:23-build/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 200 1886 - - ---- 1/1/0/0/0 0/0 "GET /v1.42/images/registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-dcfb4b66/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 200 1886 - - ---- 1/1/0/0/0 0/0 "GET /v1.42/images/sha256:16eed3dc21a621f6a6b1dfc9e4d1f891458ada8fc569eb679057867c2131d7d9/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/2 200 16459 - - ---- 1/1/0/0/0 0/0 "GET /v1.42/networks HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 404 332 - - ---- 1/1/0/0/0 0/0 "DELETE /v1.42/containers/runner-vz6k6ahn-project-109-concurrent-0-530679e51b518c43-predefined-0?force=1&v=1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/87/87 201 313 - - ---- 1/1/0/0/0 0/0 "POST /v1.42/containers/create?name=runner-vz6k6ahn-project-109-concurrent-0-530679e51b518c43-predefined-0 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 24619 - - ---- 1/1/0/0/0 0/0 "GET /v1.42/containers/25f9c4354d894137670bb687cb57f2ec7f03d715b7749cc2f9e886e9d93ea7bf/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/438/438 204 176 - - ---- 2/2/1/1/0 0/0 "POST /v1.42/containers/25f9c4354d894137670bb687cb57f2ec7f03d715b7749cc2f9e886e9d93ea7bf/start HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/542 101 197 - - ---- 2/2/0/0/0 0/0 "POST /v1.42/containers/25f9c4354d894137670bb687cb57f2ec7f03d715b7749cc2f9e886e9d93ea7bf/attach?stderr=1&stdin=1&stdout=1&stream=1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/239/239 200 256 - - ---- 1/1/0/0/0 0/0 "POST /v1.42/containers/25f9c4354d894137670bb687cb57f2ec7f03d715b7749cc2f9e886e9d93ea7bf/wait?condition=not-running HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 304 178 - - ---- 2/2/0/0/0 0/0 "POST /v1.42/containers/25f9c4354d894137670bb687cb57f2ec7f03d715b7749cc2f9e886e9d93ea7bf/stop HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 200 1886 - - ---- 2/2/0/0/0 0/0 "GET /v1.42/images/registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-dcfb4b66/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 1886 - - ---- 2/2/0/0/0 0/0 "GET /v1.42/images/sha256:16eed3dc21a621f6a6b1dfc9e4d1f891458ada8fc569eb679057867c2131d7d9/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 200 16459 - - ---- 2/2/0/0/0 0/0 "GET /v1.42/networks HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 404 332 - - ---- 2/2/0/0/0 0/0 "DELETE /v1.42/containers/runner-vz6k6ahn-project-109-concurrent-0-530679e51b518c43-predefined-1?force=1&v=1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/68/68 201 313 - - ---- 2/2/0/0/0 0/0 "POST /v1.42/containers/create?name=runner-vz6k6ahn-project-109-concurrent-0-530679e51b518c43-predefined-1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 24619 - - ---- 2/2/0/0/0 0/0 "GET /v1.42/containers/38a69f4e4dd4ec07927b110c7b318f835bc89372edbbb791bea8b4360ad5d7a6/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/397/397 204 176 - - ---- 3/3/1/1/0 0/0 "POST /v1.42/containers/38a69f4e4dd4ec07927b110c7b318f835bc89372edbbb791bea8b4360ad5d7a6/start HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/847 101 401 - - ---- 3/3/0/0/0 0/0 "POST /v1.42/containers/38a69f4e4dd4ec07927b110c7b318f835bc89372edbbb791bea8b4360ad5d7a6/attach?stderr=1&stdin=1&stdout=1&stream=1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/253/253 200 256 - - ---- 2/2/0/0/0 0/0 "POST /v1.42/containers/38a69f4e4dd4ec07927b110c7b318f835bc89372edbbb791bea8b4360ad5d7a6/wait?condition=not-running HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 304 178 - - ---- 2/2/0/0/0 0/0 "POST /v1.42/containers/38a69f4e4dd4ec07927b110c7b318f835bc89372edbbb791bea8b4360ad5d7a6/stop HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 200 6185 - - ---- 2/2/0/0/0 0/0 "GET /v1.42/images/affineurs/dind:23-build/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 200 16459 - - ---- 2/2/0/0/0 0/0 "GET /v1.42/networks HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 404 326 - - ---- 2/2/0/0/0 0/0 "DELETE /v1.42/containers/runner-vz6k6ahn-project-109-concurrent-0-530679e51b518c43-build-2?force=1&v=1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/85/85 201 313 - - ---- 2/2/0/0/0 0/0 "POST /v1.42/containers/create?name=runner-vz6k6ahn-project-109-concurrent-0-530679e51b518c43-build-2 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 200 28800 - - ---- 2/2/0/0/0 0/0 "GET /v1.42/containers/9f5c55d4f4a9f61c459d332129d9789c50b933a2b6f7ab43e3a14a012b789384/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/440/440 204 176 - - ---- 3/3/1/1/0 0/0 "POST /v1.42/containers/9f5c55d4f4a9f61c459d332129d9789c50b933a2b6f7ab43e3a14a012b789384/start HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 335 - - ---- 4/4/1/1/0 0/0 "HEAD /_ping HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/30/30 200 268 - - ---- 4/4/1/1/0 0/0 "POST /v1.42/auth HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 335 - - ---- 4/4/1/1/0 0/0 "HEAD /_ping HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 335 - - ---- 5/5/1/1/0 0/0 "HEAD /_ping HTTP/1.1" 
dockerfrontend/<NOSRV> 0/-1/-1/-1/0 403 189 - - PR-- 6/6/0/0/0 0/0 "POST /grpc HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 335 - - ---- 6/6/1/1/0 0/0 "HEAD /_ping HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 335 - - ---- 7/7/1/1/0 0/0 "HEAD /_ping HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/5/5 200 1039 - - ---- 7/7/1/1/0 0/0 "GET /v1.42/version HTTP/1.1" 
dockerfrontend/<NOSRV> 0/-1/-1/-1/0 403 189 - - PR-- 8/8/0/0/0 0/0 "POST /grpc HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/791 101 822 - - ---- 3/3/0/0/0 0/0 "POST /v1.42/containers/9f5c55d4f4a9f61c459d332129d9789c50b933a2b6f7ab43e3a14a012b789384/attach?stderr=1&stdin=1&stdout=1&stream=1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/211/211 200 256 - - ---- 2/2/0/0/0 0/0 "POST /v1.42/containers/9f5c55d4f4a9f61c459d332129d9789c50b933a2b6f7ab43e3a14a012b789384/wait?condition=not-running HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 304 178 - - ---- 2/2/0/0/0 0/0 "POST /v1.42/containers/9f5c55d4f4a9f61c459d332129d9789c50b933a2b6f7ab43e3a14a012b789384/stop HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 200 1886 - - ---- 2/2/0/0/0 0/0 "GET /v1.42/images/registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-dcfb4b66/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 1886 - - ---- 2/2/0/0/0 0/0 "GET /v1.42/images/sha256:16eed3dc21a621f6a6b1dfc9e4d1f891458ada8fc569eb679057867c2131d7d9/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/1 200 16459 - - ---- 2/2/0/0/0 0/0 "GET /v1.42/networks HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 404 332 - - ---- 2/2/0/0/0 0/0 "DELETE /v1.42/containers/runner-vz6k6ahn-project-109-concurrent-0-530679e51b518c43-predefined-3?force=1&v=1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/94/94 201 313 - - ---- 2/2/0/0/0 0/0 "POST /v1.42/containers/create?name=runner-vz6k6ahn-project-109-concurrent-0-530679e51b518c43-predefined-3 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/0 200 24618 - - ---- 2/2/0/0/0 0/0 "GET /v1.42/containers/9845069e00ce67b2dc2e3835e65eb8e8e317947c45c64c2850a98df63edd6103/json HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/491/491 204 176 - - ---- 3/3/1/1/0 0/0 "POST /v1.42/containers/9845069e00ce67b2dc2e3835e65eb8e8e317947c45c64c2850a98df63edd6103/start HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/0/587 101 117 - - ---- 3/3/0/0/0 0/0 "POST /v1.42/containers/9845069e00ce67b2dc2e3835e65eb8e8e317947c45c64c2850a98df63edd6103/attach?stderr=1&stdin=1&stdout=1&stream=1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/211/211 200 256 - - ---- 2/2/0/0/0 0/0 "POST /v1.42/containers/9845069e00ce67b2dc2e3835e65eb8e8e317947c45c64c2850a98df63edd6103/wait?condition=not-running HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 304 178 - - ---- 2/2/0/0/0 0/0 "POST /v1.42/containers/9845069e00ce67b2dc2e3835e65eb8e8e317947c45c64c2850a98df63edd6103/stop HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/2 200 16459 - - ---- 4/4/3/3/0 0/0 "GET /v1.42/networks HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/1/1 200 16459 - - ---- 4/4/2/2/0 0/0 "GET /v1.42/networks HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/3/3 200 16459 - - ---- 4/4/2/2/0 0/0 "GET /v1.42/networks HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/3/3 200 16459 - - ---- 4/4/2/2/0 0/0 "GET /v1.42/networks HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/15/15 204 176 - - ---- 4/4/3/3/0 0/0 "DELETE /v1.42/containers/9845069e00ce67b2dc2e3835e65eb8e8e317947c45c64c2850a98df63edd6103?force=1&v=1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/15/15 204 176 - - ---- 4/4/2/2/0 0/0 "DELETE /v1.42/containers/38a69f4e4dd4ec07927b110c7b318f835bc89372edbbb791bea8b4360ad5d7a6?force=1&v=1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/17/17 204 176 - - ---- 4/4/1/1/0 0/0 "DELETE /v1.42/containers/25f9c4354d894137670bb687cb57f2ec7f03d715b7749cc2f9e886e9d93ea7bf?force=1&v=1 HTTP/1.1" 
dockerfrontend dockerbackend/dockersocket 0/0/0/23/23 204 176 - - ---- 3/3/0/0/0 0/0 "DELETE /v1.42/containers/9f5c55d4f4a9f61c459d332129d9789c50b933a2b6f7ab43e3a14a012b789384?force=1&v=1 HTTP/1.1"

If you have any ideas.. Thanks !

Thomas

Defined ENV variables not used on host when deployed in swarm stack

Hi,
I deployed docker-socket-proxy in swarm mode on two hosts.
On one of them, a Synology NAS with DSM v7.1, the ENV variable values defined are not taken into account.

Here is what I get when I inspect the container:

"ALLOW_RESTARTS=0",
"AUTH=0",
"BUILD=0",
"COMMIT=0",
"CONFIGS=0",
"CONTAINERS=0",
"DISTRIBUTION=0",
"EVENTS=1",
"EXEC=0",
"IMAGES=0",
"INFO=0",
"LOG_LEVEL=info",
"NETWORKS=0",
"NODES=0",
"PING=1",
"PLUGINS=0",
"POST=0",
"SECRETS=0",
"SERVICES=0",
"SESSION=0",
"SWARM=0",
"SYSTEM=0",
"TASKS=0",
"VERSION=1",
"VOLUMES=0"

The other container on the other host have the variables as defined in the docker-compose file.

version: '3.8'

services:
  socket-proxy:
    image: tecnativa/docker-socket-proxy:latest
    deploy:
      restart_policy:
        condition: on-failure
      mode: global
      placement:
        constraints: [node.role == manager]
    hostname: "{{.Service.Name}}-{{.Node.Hostname}}"
    environment:
      - BUILD=1
      - COMMIT=1
      - CONFIGS=1
      - CONTAINERS=1
      - DISTRIBUTION=1
      - EXEC=1
      - IMAGES=1
      - INFO=1
      - NETWORKS=1
      - NODES=1
      - PLUGINS=1
      - SERVICES=1
      - SESSION=1
      - SWARM=1
      - SYSTEM=1
      - TASKS=1
      - VOLUMES=1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 2375:2375
    networks:
      socket-proxy:

networks:
  socket-proxy:
    name: socket-proxy_network
    driver: overlay
    attachable: true

On the Synology host, if I don't deploy in swarm mode and simply docker-compose up, the container will get the correct variable values.

Any idea?
The problem is maybe even not with docker-socket-proxy, but can I know for sure ?

Different permissions for different containers

I know how to use this with traefik. I've found some samples how to use it with portainer.

But on a single server I'm using both traefik and portainer. That means I must expose many endpoints (because portainer wants them), and traefik therefore sees them too. From the samples I've seen, that includes the very powerful POST.

Is this the correct approach - or can I set different permissions for different containers?

If not currently possible, please consider this a feature request?

I'd need finer-grained restrictions

ciao, thanks for this simple solution. i'd have a use-case though where only access to the endpoints containers/json and …/{id}/json (inspection), but not …/create or …/{id}/stop etc., would be needed.

it'd be therefore desirable to use environment variables like CONTAINER_LIST and CONTAINER_INSPECT to override the CONTAINER value.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.