Kantin-Petit
ceddb86198
n8n ≥ 2.18.4 sert son propre MCP : suppression du service mcp-n8n, MCP_N8N_URL pointe vers l'endpoint natif de l'instance (auth MCP Access Token Bearer). Portainer reste un sidecar officiel. Aucun changement de code (registry HTTP+Bearer inchangé). Docs + .env alignés, compose revalidé. Palier de risque : n/a (infra + config). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.6 KiB
1.6 KiB
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-internalest déclaréinternal: true: pas de route vers l'extérieur.- Seul Ollama est aussi sur
chlova-egress(il doit joindreollama.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), etapi.telegram.orgquand la surface Telegram est active. - À 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).