# socket-proxy — accès Docker filtré

`tecnativa/docker-socket-proxy` s'intercale entre le serveur MCP Portainer (et
toute brique ayant besoin de l'API Docker) et le socket Docker de l'hôte. Il
**filtre les endpoints** de l'API Docker via des variables d'env (0 = refusé,
1 = autorisé). C'est le seul à monter `/var/run/docker.sock` (en **lecture seule**).

## Phase 1 — lecture seule
Autoriser uniquement les endpoints de lecture, refuser tout le reste.

| Variable | Valeur P1 | Effet |
|---|---|---|
| `CONTAINERS` | `1` | lister/inspecter conteneurs |
| `IMAGES` | `1` | lister/inspecter images |
| `NETWORKS` | `1` | lister/inspecter réseaux |
| `VOLUMES` | `1` | lister/inspecter volumes |
| `SERVICES`/`TASKS`/`NODES` | `1` | lecture swarm (si applicable) |
| `INFO` | `1` | `docker info` |
| `VERSION` | `1` | `docker version` |
| `POST` | `0` | **refuse toute mutation** (create/start/stop/rm…) |
| `EXEC` | `0` | **refuse `exec`** dans un conteneur |
| `AUTH`/`SECRETS`/`CONFIGS` | `0` | refuse l'accès aux secrets/configs |
| `BUILD`/`COMMIT`/`IMAGES_CREATE` | `0` | refuse build/commit/pull |

> `POST=0` est la barrière clé : la plupart des actions destructrices passent par
> des requêtes POST. En Phase 1 on ne l'active **jamais**.

## Mise en œuvre
Le service est défini dans `infra/docker-compose.yml` (service `socket-proxy`),
branché **uniquement** sur `chlova-internal`, sans port publié. Le socket hôte est
monté en `:ro`. Le MCP Portainer pointe vers `tcp://socket-proxy:2375` au lieu du
socket brut.

## Rollback / durcissement
- Pour revenir en arrière : remettre toutes les variables d'écriture à `0` et
  redéployer. Le passage en Phase 2 (écriture) n'ouvrira que les endpoints
  **strictement** nécessaires à la capacité ajoutée, après review (voir
  `docs/security.md`, checklist Phase 2).
- Image **épinglée** (tag + digest) dans le compose, jamais `:latest`.