# Réseaux & exposition

> Invariant : **une seule surface exposée**, le backend CHLOVA. Tout le reste
> reste interne. Voir `docs/security.md`.

## Réseaux Docker

| Réseau | Type | Membres | But |
|---|---|---|---|
| `chlova-internal` | `internal: true` | backend, ollama, mcp-portainer, socket-proxy, (n8n + Portainer existants, à attacher) | bus interne ; **aucun accès externe** |
| `chlova-egress` | bridge | ollama uniquement | sortie contrôlée vers `ollama.com` |

- `chlova-internal` est déclaré `internal: true` : **pas de route vers l'extérieur**.
- Seul **Ollama** est aussi sur `chlova-egress` (il doit joindre `ollama.com`).
- Le backend n'a **pas** besoin d'egress en Phase 1 (Telegram en long-polling sort
  vers `api.telegram.org` → à autoriser explicitement quand la surface est activée).

## Ports publiés
- **Phase 1 : aucun.** La surface Telegram fonctionne en long-polling (le bot
  appelle Telegram, rien n'écoute en entrée).
- Phases ultérieures (API/UI CHLOVA) : exposer **uniquement** le backend derrière
  **Traefik + TLS**, et/ou via **VPN mesh** (Tailscale/Wireguard). Jamais Ollama,
  n8n, Portainer ou un serveur MCP.

## Egress (pare-feu)
- Politique par défaut : **deny**.
- Autoriser : `ollama.com` (proxy cloud), et `api.telegram.org` quand la surface
  Telegram est active. Si le MCP n8n est joint via son **domaine public** (au lieu
  de l'hôte interne), autoriser aussi ce domaine (endpoint `/mcp-server/http`, TLS).
- À appliquer au niveau hôte (iptables/nftables ou réseau Docker dédié) ; documenté
  ici, mis en œuvre côté infra serveur (hors dépôt si géré par l'hôte).

## Rappels
- Ollama **n'a aucune auth native** → ne jamais lui publier de port.
- Accès Docker **uniquement** via `socket-proxy` (jamais le socket brut).