Un fichier .env ignoré par Git reste un fichier en clair. Dans une stack Docker Compose, il finit facilement dans une copie de migration, une sauvegarde, une archive de support ou, un jour, l’historique du dépôt.
SOPS et age permettent de corriger une partie du problème sans déployer un gestionnaire de secrets centralisé. Le principe est simple : le dépôt contient un fichier chiffré, les clés privées restent hors de Git et le serveur ne déchiffre que les valeurs nécessaires au déploiement.
Docker Compose reçoit ensuite ces valeurs sous forme de fichiers montés dans /run/secrets/. Les mots de passe ne passent plus par environment: et ne finissent plus dans la configuration du conteneur.
Cette méthode convient bien à un homelab, à quelques VPS ou à une petite infrastructure pilotée par Git. SOPS reste un outil de chiffrement de fichiers, pas un gestionnaire de secrets centralisé, et ne protège pas un hôte déjà compromis.
Immich 3.0 apporte l’édition photo non destructive sur mobile, les workflows d’automatisation, le HLS, l’OCR, et plusieurs améliorations de maintenance. La migration est simple pour la plupart des utilisateurs, mais les intégrations API tierces nécessitent une vérification.
Le tag latest est confortable.
On écrit un compose.yml, on lance docker compose up -d, et le service démarre. Pas besoin de choisir une version de PostgreSQL, Redis, Traefik, Gitea, Vaultwarden ou n’importe quelle application auto-hébergée.
Le problème, c’est que latest ne veut pas dire “dernière version stable adaptée à mon environnement”. Ça veut seulement dire : “ce tag pointe vers quelque chose dans le registre au moment où Docker le résout”.
Ce quelque chose peut changer sans que votre fichier Compose change.
Pour une stack de test, ce n’est pas très grave. Pour une base de données, un reverse proxy exposé, un service d’authentification ou une application avec des volumes persistants, c’est une mauvaise convention d’exploitation.
Le vrai sujet n’est pas Docker. C’est la reproductibilité.
Dans le premier article sur Pangolin, j’avais volontairement laissé CrowdSec de côté.
Pas parce que CrowdSec n’est pas utile. Au contraire. Mais parce qu’une pile Pangolin doit d’abord être comprise avant d’ajouter des briques de sécurité, des bouncers, des dashboards et des automatisations. Une fois Pangolin stable, la question revient naturellement :
Comment visualiser proprement ce que CrowdSec voit et bloque, sans exposer une interface d’administration sensible sur Internet ?
C’est là que CrowdSec Manager devient intéressant.
L’objectif de ce test est simple :
installer CrowdSec Manager à côté de la stack CrowdSec ; ne pas publier son port 8080 sur Internet ; le rendre accessible uniquement via Pangolin ; protéger l’accès avec le SSO Pangolin ; garder les secrets Newt dans Gitea Actions, pas dans Git.
