Kantin-Petit
0f63b3addd
Modèle de menace centré prompt-injection + défenses par couche (surface réduite, socket-proxy obligatoire, scoping tokens, egress ollama.com only, secrets par référence, lecture seule renforcée, audit). Documente réseaux interne/egress et filtrage Docker en lecture seule P1. Normalise les fins de ligne (.gitattributes). Palier de risque : n/a (doc + conventions). 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-n8n, mcp-portainer, socket-proxy, (n8n, portainer existants) | 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).