Djeex/docudjeex
1
1
Fork 0
Code Issues Pull Requests Actions Projects Wiki Activity

Put Docker Socket Proxy in front of every container that needs the Docker API instead of mounting docker.sock directly

Browse Source
This commit is contained in:
Djeex
2026-09-07 13:42:40 +02:00
parent 5548287c65
commit 81c54c9afc
10 changed files with 401 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/fr/3.serveex/2.core/2.docker.md
+77 -4
View File
@@ -94,15 +94,52 @@ services:
container_name: dockge
ports:
- 3555:5001 # le port accessible sur le réseau local sera 3555
environment:
- DOCKER_HOST=tcp://docker-socket-proxy:2375
- DOCKGE_STACKS_DIR=/srv/docker
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /srv/docker/dockge/data:/app/data
- /srv/docker:/srv/docker
networks:
- dockge-internal
depends_on:
- docker-socket-proxy
docker-socket-proxy:
image: lscr.io/linuxserver/socket-proxy:latest
container_name: docker-socket-proxy-dockge
security_opt:
- no-new-privileges:true
networks:
- dockge-internal
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
- DOCKGE_STACKS_DIR=/srv/docker
- CONTAINERS=1
- IMAGES=1
- NETWORKS=1
- VOLUMES=1
- EXEC=1
- INFO=1
- SYSTEM=1
- POST=1
- ALLOW_START=1
- ALLOW_STOP=1
- ALLOW_RESTARTS=1
restart: unless-stopped
read_only: true
tmpfs:
- /run
networks:
dockge-internal:
name: dockge-internal
```
::warning
Dockge a besoin d'accéder à l'API Docker pour gérer toutes les autres stacks de ce serveur, ce qui équivaut à un accès root sur l'hôte. Plutôt que de monter directement `/var/run/docker.sock`, cette config place **Docker Socket Proxy** devant, qui n'autorise que les permissions dont Dockge a réellement besoin (conteneurs, images, réseaux, volumes, exec, actions de cycle de vie), sur leur propre réseau interne. Dockge n'a pas d'authentification intégrée par défaut, n'exposez donc jamais le port `3555` au-delà de votre réseau local sans le placer derrière [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik).
::
Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et :kbd{value="Ctrl+X"} pour quitter.
#### Lancer le conteneur
@@ -149,12 +186,44 @@ services:
- WATCHTOWER_LABEL_ENABLE=true
- WATCHTOWER_CLEANUP=true
- WATCHTOWER_REMOVE_VOLUMES=true
- DOCKER_HOST=tcp://docker-socket-proxy:2375
# Notifications Discord - décommentez si utilisées
#- WATCHTOWER_NOTIFICATIONS=slack
#- WATCHTOWER_NOTIFICATION_SLACK_IDENTIFIER=Watchtower
#- WATCHTOWER_NOTIFICATION_SLACK_HOOK_URL=${WH_URL}
networks:
- watchtower-internal
depends_on:
- docker-socket-proxy
docker-socket-proxy:
image: lscr.io/linuxserver/socket-proxy:latest
container_name: docker-socket-proxy-watchtower
security_opt:
- no-new-privileges:true
networks:
- watchtower-internal
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
- CONTAINERS=1
- IMAGES=1
- NETWORKS=1
- VOLUMES=1
- INFO=1
- SYSTEM=1
- POST=1
- ALLOW_START=1
- ALLOW_STOP=1
- ALLOW_RESTARTS=1
restart: unless-stopped
read_only: true
tmpfs:
- /run
networks:
watchtower-internal:
name: watchtower-internal
```
::warning
@@ -162,6 +231,10 @@ services:
`WATCHTOWER_REMOVE_VOLUMES=true` supprime les volumes anonymes d'un conteneur dès qu'il est mis à jour. Combiné à un tag `latest`, une mise à jour automatique peut silencieusement effacer les données de toute app qui stocke encore quelque chose dans un volume anonyme (sans nom) plutôt qu'un bind mount.
::
::note
Cette config place **Docker Socket Proxy** devant l'API Docker plutôt que de monter directement `/var/run/docker.sock`, afin que Watchtower n'obtienne que les permissions dont il a réellement besoin (lister/tirer les images, recréer les conteneurs) plutôt qu'un accès root complet à l'hôte.
::
#### Renseigner vos variables d'environnement
Remplissez la section `.env` dans Dockge avec ce qui suit :
content/fr/3.serveex/4.monitoring/2.dozzle.md
+35 -4
View File
@@ -43,10 +43,41 @@ services:
- .env
environment:
- DOZZLE_HOSTNAME=${DOMAIN}
- DOCKER_HOST=tcp://docker-socket-proxy:2375
networks:
- dozzle-internal
depends_on:
- docker-socket-proxy
docker-socket-proxy:
image: lscr.io/linuxserver/socket-proxy:latest
container_name: docker-socket-proxy-dozzle
security_opt:
- no-new-privileges:true
networks:
- dozzle-internal
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
- CONTAINERS=1
- IMAGES=1
- INFO=1
- EVENTS=1
- ALLOW_LOGS=1
restart: unless-stopped
read_only: true
tmpfs:
- /run
networks:
dozzle-internal:
name: dozzle-internal
```
::note
Dozzle ne fait que lire les logs des conteneurs, donc cette config place **Docker Socket Proxy** devant l'API Docker plutôt que de monter directement `/var/run/docker.sock`, en gardant `POST` totalement désactivé : Dozzle peut lister les conteneurs et streamer leurs logs, rien de plus.
::
::tip{icon=""}
✨ __Astuce :__ ajoutez le label watchtower à chaque conteneur pour automatiser les mises à jour
@@ -189,7 +220,7 @@ Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et
Et voilà, Dozzle est maintenant exposé !
## Protéger Dozzle avec TinyAuth
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `dozzle.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy) :
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `dozzle.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protéger-une-application-via-le-reverse-proxy) :
```nginx [dozzle.subdomain.conf]{26-38,41-42}
## Version 2023/12/19
@@ -259,11 +290,11 @@ server {
}
```
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
::
::tip{icon=""}
✨ __Astuce :__ vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `dozzle.subdomain.conf` et en retirant le `#` devant `include /config/nginx/authentik-server.conf;`{lang=nginx} et `include /config/nginx/authentik-location.conf;`{lang=nginx}. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy).
✨ __Astuce :__ vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `dozzle.subdomain.conf` et en retirant le `#` devant `include /config/nginx/authentik-server.conf;`{lang=nginx} et `include /config/nginx/authentik-location.conf;`{lang=nginx}. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
::
content/fr/3.serveex/4.monitoring/4.beszel.md
+45 -6
View File
@@ -53,13 +53,35 @@ services:
network_mode: host
volumes:
- ./socket:/beszel_socket
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
LISTEN: /beszel_socket/beszel.sock
DOCKER_HOST: tcp://127.0.0.1:2375
# Ne retirez pas les guillemets autour de la clé
KEY: ${KEY}
depends_on:
- docker-socket-proxy
docker-socket-proxy:
image: lscr.io/linuxserver/socket-proxy:latest
container_name: docker-socket-proxy-beszel
security_opt:
- no-new-privileges:true
ports:
- 127.0.0.1:2375:2375
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
- CONTAINERS=1
restart: unless-stopped
read_only: true
tmpfs:
- /run
```
::note
`beszel-agent` tourne avec `network_mode: host`, il ne peut donc pas rejoindre un réseau interne dédié comme les autres stacks proxifiées de ce site ; à la place, **Docker Socket Proxy** publie son API sur `127.0.0.1` uniquement, joignable depuis l'agent via l'interface de loopback de l'hôte, avec seulement `CONTAINERS=1` activé puisque l'agent n'a besoin que de lire les statistiques des conteneurs.
::
::tip{icon=""}
✨ __Astuce :__ ajoutez le label Watchtower à chaque conteneur pour automatiser les mises à jour.
@@ -122,11 +144,28 @@ services:
container_name: beszel-agent
restart: unless-stopped
network_mode: host
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
LISTEN: ${PORT}
KEY: ${KEY}
DOCKER_HOST: tcp://127.0.0.1:2375
depends_on:
- docker-socket-proxy
docker-socket-proxy:
image: lscr.io/linuxserver/socket-proxy:latest
container_name: docker-socket-proxy-beszel
security_opt:
- no-new-privileges:true
ports:
- 127.0.0.1:2375:2375
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
- CONTAINERS=1
restart: unless-stopped
read_only: true
tmpfs:
- /run
```
Et dans le `.env` :
@@ -253,7 +292,7 @@ Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et
Et voilà ! Beszel est maintenant exposé !
## Protéger Beszel avec TinyAuth
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `beszel.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy) :
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `beszel.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protéger-une-application-via-le-reverse-proxy) :
```nginx [beszel.subdomain.conf]{26-38,41-42}
## Version 2023/12/19
@@ -316,11 +355,11 @@ server {
}
```
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
::
::tip{icon=""}
✨ Vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `beszel.subdomain.conf` et en retirant le `#` devant `include /config/nginx/authentik-server.conf;` et `include /config/nginx/authentik-location.conf;`. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy).
✨ Vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `beszel.subdomain.conf` et en retirant le `#` devant `include /config/nginx/authentik-server.conf;` et `include /config/nginx/authentik-location.conf;`. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
::
content/fr/3.serveex/91.advanced/1.authentik.md
+46 -11
View File
@@ -19,7 +19,7 @@ Authentik gère aussi l'authentification multifacteur, dont le TOTP (un code gé
C'est une excellente alternative au VPN pour exposer des services en toute sécurité, en particulier ceux qui n'ont ni MFA ni protection de connexion (le tableau de bord de SWAG par exemple).
Authentik dispose d'une [documentation fournie](https://docs.goauthentik.io/docs/installation/docker-compose) et de [très bons tutoriels de Cooptonian](https://www.youtube.com/@cooptonian). Ici, nous verrons les bases en prenant Dockge comme exemple.
Authentik dispose d'une [documentation fournie](https://docs.goauthentik.io/install-config/install/docker-compose) et de [très bons tutoriels de Cooptonian](https://www.youtube.com/@cooptonian). Ici, nous verrons les bases en prenant Dockge comme exemple.
Il y a deux modes principaux à connaître :
@@ -156,24 +156,55 @@ services:
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
# `user: root` and the docker socket volume are optional.
# See more for the docker socket integration here:
# `user: root` et l'intégration Docker ci-dessous sont optionnels, uniquement
# nécessaires si vous voulez qu'Authentik gère automatiquement des outposts
# intégrés sur cet hôte. Voir :
# https://goauthentik.io/docs/outposts/integrations/docker
# Removing `user: root` also prevents the worker from fixing the permissions
# on the mounted folders, so when removing this make sure the folders have the correct UID/GID
# (1000:1000 by default)
# Retirer `user: root` empêche aussi le worker de corriger les permissions
# sur les dossiers montés, donc si vous le retirez, assurez-vous que ces
# dossiers ont le bon UID/GID (1000:1000 par défaut)
user: root
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- ./media:/media
- ./certs:/certs
- ./custom-templates:/templates
- ./ssh:/authentik/.ssh
networks:
- default
- authentik-internal
env_file:
- .env
depends_on:
- postgresql
- redis
- docker-socket-proxy
docker-socket-proxy:
image: lscr.io/linuxserver/socket-proxy:latest
container_name: docker-socket-proxy-authentik
security_opt:
- no-new-privileges:true
networks:
- authentik-internal
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
- CONTAINERS=1
- IMAGES=1
- NETWORKS=1
- INFO=1
- POST=1
- ALLOW_START=1
- ALLOW_STOP=1
- ALLOW_RESTARTS=1
restart: unless-stopped
read_only: true
tmpfs:
- /run
networks:
authentik-internal:
name: authentik-internal
volumes:
database:
@@ -182,6 +213,10 @@ volumes:
driver: local
```
::note
Ceci ajoute **Docker Socket Proxy** pour que l'intégration Docker optionnelle n'ait jamais besoin de `/var/run/docker.sock` monté directement dans le worker. Si vous l'activez, définissez l'URL Docker de la connexion dans l'interface d'administration sur `http://docker-socket-proxy:2375` plutôt que le chemin du socket local, comme le recommande [la documentation d'Authentik](https://goauthentik.io/docs/outposts/integrations/docker) pour les configurations avec socket-proxy.
::
### Démarrer la configuration initiale
Dans le fichier `.env`, les variables `PG_PASS` et `AUTHENTIK_SECRET_KEY` sont déjà renseignées.
@@ -322,7 +357,7 @@ Allez dans _Settings_, cliquez sur la section _MFA_, puis sur _Register_. Choisi
Un code à usage unique vous sera désormais demandé à chaque connexion.
## Protéger une app native
Authentik est nativement compatible avec plusieurs applications. Vous trouverez la liste et [le support ici](https://docs.goauthentik.io/integrations/services/).
Authentik est nativement compatible avec plusieurs applications. Vous trouverez la liste et [le support ici](https://integrations.goauthentik.io/).
## Protéger une app par reverse proxy
SWAG permet d'insérer la page de connexion d'Authentik entre une requête et l'accès à votre service. Pour cela :
@@ -458,7 +493,7 @@ En ligne de commande :
```bash [Terminal]
sudo nano /srv/docker/authentik-outpost/compose.yaml
```
Collez la configuration suivante, en mettant à jour la version dans `{AUTHENTIK_TAG:proxy:2024.2.3}`{lang=properties} pour correspondre à celle de votre serveur Authentik.
Collez la configuration suivante, en mettant à jour la version dans `ghcr.io/goauthentik/proxy:2026.2`{lang=properties} pour correspondre à celle de votre serveur Authentik.
```yaml [compose.yaml]
---
@@ -466,7 +501,7 @@ version: "3.5"
services:
authentik_proxy:
container_name: authentik-outpost
image: ghcr.io/goauthentik/proxy:2024.2.3
image: ghcr.io/goauthentik/proxy:2026.2
# Optionally specify which networks the container should be
# might be needed to reach the core authentik server
restart: unless-stopped
@@ -585,7 +620,7 @@ Enregistrez avec :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"}, et quittez avec
### Terminé !
::
Configurez ensuite les applications à protéger comme vous l'avez fait sur votre serveur principal, qu'elles soient [natives](/serveex/advanced/authentik/#protecting-a-native-app) ou protégées via [reverse proxy](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy).
Configurez ensuite les applications à protéger comme vous l'avez fait sur votre serveur principal, qu'elles soient [natives](/serveex/advanced/authentik/#protecting-a-native-app) ou protégées via [reverse proxy](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
## Migrer une base de données Authentik
content/fr/3.serveex/91.advanced/2.arcane.md
+3 -3
View File
@@ -72,7 +72,7 @@ services:
docker-socket-proxy:
image: lscr.io/linuxserver/socket-proxy:latest
container_name: arcane-docker-proxy
container_name: docker-socket-proxy-arcane
security_opt:
- no-new-privileges:true
networks:
@@ -248,7 +248,7 @@ Et voilà ! Arcane est maintenant accessible depuis internet.
## Connecter un hôte distant
Arcane peut gérer plusieurs hôtes Docker depuis une seule instance. Chaque hôte distant fait tourner un conteneur **agent** léger qui se reconnecte à Arcane. Plutôt que d'exposer cette connexion sur internet, nous la ferons passer par le [VPN WireGuard](/serveex/core/wireguard) déjà mis en place plus tôt, ainsi le trafic de l'agent ne quitte jamais votre réseau privé.
::note{to="/serveex/core/wireguard#client-server-setup"}
::note{to="/serveex/core/wireguard#sur-le-serveur-client"}
Ceci suppose que l'hôte Arcane et l'hôte distant font déjà tourner leur propre client WireGuard, connectés à votre VPN comme décrit dans **Client Server Setup**. Notez l'adresse VPN que wg-easy a attribuée à l'__hôte Arcane__ (par exemple `10.8.0.3`) ; c'est l'adresse que visera l'agent distant ci-dessous.
::
@@ -299,7 +299,7 @@ Arcane gère OIDC nativement, vous pouvez donc exiger une connexion Pocket ID av
::steps{level="3"}
### Enregistrer Arcane comme client OIDC
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#registering-an-oidc-client) nommé `arcane`, avec cette URL de callback :
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#enregistrer-un-client-oidc) nommé `arcane`, avec cette URL de callback :
```text
https://arcane.mondomaine.fr/auth/oidc/callback