Set-OPS-Public/roles/serveur_ops_site/meta/authentification.yml

---
# Position de ce role dans la directive d'authentification (D-38..D-41).
# Voir docs/authentification.md. Gardee par la preuve P29.
authentification:
  portee: sans-auth-humaine
  mecanisme: aucun
  formulaire_local: sans-objet
  secours: "Acces SSH a l'hote, puis `sudo -iu setops`"
  raison: >-
    Ce role n'expose aucune interface : il DETIENT un pouvoir au lieu d'en offrir un.
    Ce qui le protege n'est pas une authentification mais le fait que la voute deposee
    reste CHIFFREE et que son mot de passe soit tape a l'execution, jamais stocke.
runner : separer le pouvoir de configurer de celui de materialiser La ligne de partage est celle des voutes. serveur_ops calcule et configure -- voute du tenant, SSH chez lui. serveur_ops_site materialise -- voute du SITE, API de l'hyperviseur, jamais de SSH chez un tenant. Un runner par tenant qui materialiserait mettrait la voute du SITE en N exemplaires. Un runner unique qui ferait tout traverserait le default-deny inter-tenant et rendrait l'emancipation impossible. Le role depose la voute CHIFFREE et relit l'en-tete apres avoir ecrit : sans `decrypt: false`, Ansible dechiffre la source quand il detient le mot de passe -- constate le jour meme, 776 octets en clair au lieu de 3465. Controle negatif fait, la garde mord. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 2026-08-24 15:30:03 -04:00			`---`
			`# Position de ce role dans la directive d'authentification (D-38..D-41).`
			`# Voir docs/authentification.md. Gardee par la preuve P29.`
			`authentification:`
			`portee: sans-auth-humaine`
			`mecanisme: aucun`
			`formulaire_local: sans-objet`
			secours: "Acces SSH a l'hote, puis `sudo -iu setops`"
			`raison: >-`
			`Ce role n'expose aucune interface : il DETIENT un pouvoir au lieu d'en offrir un.`
			`Ce qui le protege n'est pas une authentification mais le fait que la voute deposee`
			`reste CHIFFREE et que son mot de passe soit tape a l'execution, jamais stocke.`