gilles
0fbca06d3d
Cartographie complète (liste_taches/coherence_taches), briefs tacheN + gates validation_tacheN, design tâche 2 (docs/design/tache2/), specs/plans jalon 1-2 et tâche 1.9/2 (Phase 1, Phase 2, SJ-0→3). Validations consignées (1.9 ✅, 2-8 🟡). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
71 lines
4.7 KiB
Markdown
71 lines
4.7 KiB
Markdown
# 70 — Note de sécurité : frontière Hermes/MCP et actions destructives
|
|
|
|
> Livrable §4.8. Tranche §3.7 (sécurité prune/scripts) et §3.8 (surface MCP). Aligné `CLAUDE.md` (sécurité non négociable) et `validation_tache2.md §3`/§6/§7/§8.
|
|
|
|
---
|
|
|
|
## 1. Ce qui ne doit JAMAIS atteindre Hermes / MCP / un prompt LLM
|
|
|
|
- Mots de passe SSH, **sudo password**, passphrases de clés, clés privées.
|
|
- Tokens / credentials de registry Docker (`~/.docker/config.json`, credential helpers, tokens d'auth).
|
|
- Toute variable de champ de type `secret` d'un profil post-install.
|
|
- URLs contenant des identifiants (`https://user:pass@…`), en-têtes d'auth, chaînes de connexion.
|
|
- Le **log brut complet** (archivé séparément, jamais inliné dans un prompt).
|
|
|
|
Mécanismes :
|
|
- Les secrets vivent uniquement dans `machine_credentials` (chiffrés au repos), injectés **uniquement** via `runScriptSudo` sur **stdin** (`sudo -S -p ''`) — jamais dans le corps du script, jamais en argument, jamais loggés.
|
|
- Le JSON canonique métier ne contient **aucun** champ secret (cf. `PostInstallResult.variablesUsed` = non sensible uniquement).
|
|
- **Nettoyage des erreurs** avant UI/MCP : un filtre déterministe masque les motifs sensibles (`https?://[^/@\s]+:[^/@\s]+@`, `Authorization:`, chemins `*/config.json`, `token=…`) dans les lignes d'erreur Docker/APT avant affichage et avant réduction Hermes.
|
|
|
|
---
|
|
|
|
## 2. Actions destructives → validation explicite côté webapp
|
|
|
|
Toute action modifiant l'état de la machine de façon non triviale passe par une **confirmation UI explicite** et est tracée comme `action_request` (`tache1.9.md §10`).
|
|
|
|
| Action | Risque | Validation |
|
|
|---|---|---|
|
|
| `apt_dist_upgrade` / `apt_full_upgrade` | peut supprimer des paquets | confirmation explicite si `removed`/`held` |
|
|
| `apt_autoremove` | supprime des paquets | confirmation explicite |
|
|
| `reboot` / `reboot_verified` | redémarrage | confirmation explicite |
|
|
| `docker_compose_apply` | recrée les conteneurs | confirmation explicite |
|
|
| `docker_prune_images` (agressif `-a`) | supprime des images non dangling | confirmation explicite distincte |
|
|
| `docker_compose_down` | arrête le stack | confirmation forte ; `--volumes`/`--rmi` interdits au MVP |
|
|
| `post_install:identity_network` | change le réseau / coupe la connexion | preview obligatoire + sauvegarde fichiers + stratégie de reconnexion planifiée |
|
|
| `apt_proxy persistent` | écrit dans `/etc/apt/apt.conf.d` | preview |
|
|
|
|
Règle d'or : **Hermes peut recommander/proposer, mais ne déclenche jamais directement** une action à risque. Le déclenchement passe par l'opérateur via l'UI (ou un `action_request` approuvé).
|
|
|
|
Actions sûres sans validation : `apt_update_analyze`, `docker_scan`, `docker_inspect_current`, `machine_probe`, `apt_clean`. `docker_pull_check` est **non passif** (écrit dans le cache images) mais non applicatif : pas de validation destructive, mais isolé du chemin de scan pur.
|
|
|
|
---
|
|
|
|
## 3. Surface MCP minimale (décision §3.8)
|
|
|
|
On **réutilise la surface v1** du rapport / `CLAUDE.md`, sans nouvelle primitive d'exécution SSH :
|
|
|
|
| Outil MCP | Rôle | Renvoie un secret ? |
|
|
|---|---|---|
|
|
| `list_machines` | liste les machines (vue publique, sans secret) | non |
|
|
| `get_machine_snapshot` | dernier snapshot réduit (APT + Docker) | non |
|
|
| `get_machine_execution` | résultat d'exécution réduit + réfs logs/rapport | non |
|
|
| `list_templates` | liste des templates disponibles | non |
|
|
| `preview_template` | rendu d'un template avec **masquage des secrets** | non |
|
|
| `run_refresh` | déclenche un refresh/analyse (action sûre) | non |
|
|
| `run_action` | déclenche une action **déjà autorisée** ; les actions destructives exigent une validation webapp préalable | non |
|
|
| `search_reports` | recherche dans les rapports archivés | non |
|
|
|
|
Principes :
|
|
- Le **MCP est une façade** de l'API métier : aucune logique SSH dedans, aucun secret.
|
|
- Aucun nouvel outil pour Docker/post-install : les nouvelles capacités passent par `run_action(actionType, params)` avec le **filtrage d'autorisation** de la route `POST /api/machines/:id/actions`. Surface stable et petite = agents fiables.
|
|
- `run_action` sur une action destructive non encore validée → renvoie un `action_request` en attente, **pas** une exécution.
|
|
- Audit : tout appel MCP est journalisé (`mcp_audit_log`, `tache1.9.md §11`) avec `request_json` réduit (sans secret).
|
|
|
|
---
|
|
|
|
## 4. Traçabilité
|
|
|
|
- Chaque exécution : log brut archivé (`raw_artifacts`/`rawLogPath`, `redacted=1`), rapport Markdown (`reports`), `important_json` réduit.
|
|
- Les changements réseau/Docker sont explicitement marqués dans le rapport avec les prochaines actions attendues (reconnexion, relogin groupe docker, reboot).
|
|
- Les secrets ne figurent ni dans les rapports, ni dans les logs UI, ni dans le MCP.
|