Kantin-Petit
bfae5bbbdb
Confirme MCP_N8N_URL = .../mcp-server/http (hôte interne préféré, URL publique TLS possible + egress du domaine). Note egress dans networks.md. Palier de risque : n/a (doc). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.8 KiB
1.8 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. 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).