Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Set-OPS-Public/docs/audit/preuve-2026-08-08.md

68 lines
5.9 KiB
Markdown
Raw Normal View History

identite : « mot de passe oublie » — raccord SMTP derive du plan Le realm portait une politique d'acces complete et aucun moyen d'ecrire a qui que ce soit. Tout oubli remontait donc a l'exploitant, qui n'avait d'autre choix que de manipuler le mot de passe d'autrui. - serveur_keycloak/tasks/courriel-realm.yml : reconcilie smtpServer et resetPasswordAllowed ; hote du relais DERIVE de applications.postfix.hote, et refus explicite si le plan ne declare pas de MTA. - passe par l'API d'administration : kcadm.sh accepte les deux formes -s sur une map, sort en succes et n'ecrit rien (smtpServer reste vide). - amorcage_acces_courriel redevient a declarer : cette adresse designe une personne, hors du systeme qu'on amorce ; une boite interne serait illisible tant qu'on n'a pas l'acces qu'on cherche justement a recuperer. - autorisation.md §6.6 : le mecanisme, ses deux conditions, et l'ecart d'adresse laisse par l'ancien mode READ_ONLY de la federation. Preuve : banniere SMTP lue depuis idm-01, RCPT TO accepte, execute-actions-email declenche, MTA en starttls -> relay=mx.chezlepro.ca status=sent (250). Second deploiement changed=0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 06:08:06 -04:00
# Preuve de conformite — Set-OPS — 2026-08-08
> Genere par `make prouver` (`scripts/prouver.py`). **Rejouable** : relancer
> reproduit ce rapport. Chaque preuve rejoue l'outillage existant du depot ;
> aucune validation n'est reimplementee ici. Voir le mode d'emploi :
> [`docs/audit/README.md`](README.md), et le registre trace :
> [`docs/audit/affirmations.md`](affirmations.md).
- **Instance** : `instance` — inventaire `instance/inventories/principal/hosts.yml`
make raser : la seule commande destructive du moteur, avec ses quatre verrous Ajoutee pour rendre la reconstruction from-zero REPETABLE — un test qu'on ne peut jouer qu'une fois n'est pas une recette. Verrous, tous eprouves avant usage : - VMID derives du plan uniquement (le gabarit dore est structurellement exclu) - le NOM doit correspondre : un VMID du plan sous un autre nom fait refuser l'operation ENTIERE. Pas theorique — le 2026-08-07 une VM heritee portait un VMID du plan sous le nom web-frontal-01 et proxmox_kvm rapportait ok. - il faut NOMMER l'ecosysteme (INSTANCE=) : le symlink instance/ peut pointer n'importe ou ; taper le nom distingue le POC de la production. - CONFIRMER=true ; sans lui, inventaire et rien d'autre. Le verrou du nom est le seul qu'on ne peut pas eprouver sur le vrai cluster sans y fabriquer une collision : scripts/tests/test_raser.py l'isole derriere un faux cluster, rattache a P02. Harnais : 31 preuves, 0 sautee. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 14:22:04 -04:00
- **Verdict** : ✅ CONFORME (31 OK · 0 echec · 0 saute)
identite : « mot de passe oublie » — raccord SMTP derive du plan Le realm portait une politique d'acces complete et aucun moyen d'ecrire a qui que ce soit. Tout oubli remontait donc a l'exploitant, qui n'avait d'autre choix que de manipuler le mot de passe d'autrui. - serveur_keycloak/tasks/courriel-realm.yml : reconcilie smtpServer et resetPasswordAllowed ; hote du relais DERIVE de applications.postfix.hote, et refus explicite si le plan ne declare pas de MTA. - passe par l'API d'administration : kcadm.sh accepte les deux formes -s sur une map, sort en succes et n'ecrit rien (smtpServer reste vide). - amorcage_acces_courriel redevient a declarer : cette adresse designe une personne, hors du systeme qu'on amorce ; une boite interne serait illisible tant qu'on n'a pas l'acces qu'on cherche justement a recuperer. - autorisation.md §6.6 : le mecanisme, ses deux conditions, et l'ecart d'adresse laisse par l'ancien mode READ_ONLY de la federation. Preuve : banniere SMTP lue depuis idm-01, RCPT TO accepte, execute-actions-email declenche, MTA en starttls -> relay=mx.chezlepro.ca status=sent (250). Second deploiement changed=0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 06:08:06 -04:00
## Preuves
| # | Preuve | Affirmations | Statut | Detail |
|---|---|---|---|---|
devis des certificats : disque contre memoire, et l'AC etait expiree Deuxieme application du patron devis/applicateur aux services. Trouve a la premiere execution : sur infra-pki-01 — l'autorite elle-meme — le certificat etait expire depuis plus de 8 h et le renouvellement echouait toutes les 14 minutes sur « 'step ca renew' requires the '--ca-url' flag ». Rien ne le signalait. Cause : sur l'hote de l'AC, /etc/step est le STEPPATH du SERVEUR, pas un amorcage client — pas de defaults.json, et l'unite de renouvellement en dependait. La lecon etait deja ecrite dans le commentaire de la tache d'emission (« l'autorite ne bootstrape pas »), jamais reportee sur l'unite. Le role ne pouvait pas non plus se soigner : la re-emission ne regardait que la FORME (cert absent ou SAN manquant), jamais la validite. client_pki verifie desormais l'echeance (client_pki_marge_renouvellement). Ce qu'il a fallu desapprendre : les certificats vivent 24 h et se renouvellent toutes les ~14 min ; « empreinte servie != empreinte disque » est l'etat NORMAL. Comparer les empreintes aurait donne un verificateur qui crie en permanence. Le signal est l'echeance de ce qui est SERVI, plus l'absence de client_pki_reload_services. Le devis a d'abord menti, du defaut meme qu'il traque : include_vars au niveau du play prime sur les group_vars. Et le premier correctif a PARU marcher — set_fact accepte un dictionnaire entier en argument libre sans erreur et n'en fait rien. Il faut reimposer cle par cle. Les deux devis sont corriges et le piege est consigne dans docs/devis-services.md avant d'ecrire le prochain. Verifie dans les deux sens : CONFORME sur 14 hotes ; sur un releve ou l'on rejoue une copie perimee en memoire, 2 ecarts et code de sortie 1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 07:20:56 -04:00
| P01 | Lint (ansible-lint) | AFF-006 | ✅ OK |  |
make raser : la seule commande destructive du moteur, avec ses quatre verrous Ajoutee pour rendre la reconstruction from-zero REPETABLE — un test qu'on ne peut jouer qu'une fois n'est pas une recette. Verrous, tous eprouves avant usage : - VMID derives du plan uniquement (le gabarit dore est structurellement exclu) - le NOM doit correspondre : un VMID du plan sous un autre nom fait refuser l'operation ENTIERE. Pas theorique — le 2026-08-07 une VM heritee portait un VMID du plan sous le nom web-frontal-01 et proxmox_kvm rapportait ok. - il faut NOMMER l'ecosysteme (INSTANCE=) : le symlink instance/ peut pointer n'importe ou ; taper le nom distingue le POC de la production. - CONFIRMER=true ; sans lui, inventaire et rien d'autre. Le verrou du nom est le seul qu'on ne peut pas eprouver sur le vrai cluster sans y fabriquer une collision : scripts/tests/test_raser.py l'isole derriere un faux cluster, rattache a P02. Harnais : 31 preuves, 0 sautee. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 14:22:04 -04:00
| P02 | Tests unitaires (inventory_host) | — | ✅ OK | >>> le verrou tient : aucune VM n'aurait ete touchee |
identite : « mot de passe oublie » — raccord SMTP derive du plan Le realm portait une politique d'acces complete et aucun moyen d'ecrire a qui que ce soit. Tout oubli remontait donc a l'exploitant, qui n'avait d'autre choix que de manipuler le mot de passe d'autrui. - serveur_keycloak/tasks/courriel-realm.yml : reconcilie smtpServer et resetPasswordAllowed ; hote du relais DERIVE de applications.postfix.hote, et refus explicite si le plan ne declare pas de MTA. - passe par l'API d'administration : kcadm.sh accepte les deux formes -s sur une map, sort en succes et n'ecrit rien (smtpServer reste vide). - amorcage_acces_courriel redevient a declarer : cette adresse designe une personne, hors du systeme qu'on amorce ; une boite interne serait illisible tant qu'on n'a pas l'acces qu'on cherche justement a recuperer. - autorisation.md §6.6 : le mecanisme, ses deux conditions, et l'ecart d'adresse laisse par l'ancien mode READ_ONLY de la federation. Preuve : banniere SMTP lue depuis idm-01, RCPT TO accepte, execute-actions-email declenche, MTA en starttls -> relay=mx.chezlepro.ca status=sent (250). Second deploiement changed=0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 06:08:06 -04:00
| P03 | Diff-vide du plan (inventaire genere) | AFF-001, AFF-004, AFF-030, AFF-031, AFF-032 | ✅ OK | DIFF VIDE : le plan reproduit exactement l'inventaire actuel. Bascule possible. |
| P04 | Groupes <-> playbooks homonymes | AFF-008 | ✅ OK | |
| P05 | Dependances causales de groupes | AFF-009, AFF-084 | ✅ OK | |
| P06 | Validateurs de registres (serveurs/apps/bases/domaines) | AFF-003 | ✅ OK | Registre des domaines valide. |
| P07 | GUI (node --check) | AFF-033 | ✅ OK | JS du GUI : syntaxe valide (node --check). |
| P08 | Orchestration (couches + graphe) | AFF-070 | ✅ OK | Orchestration coherente : 30 groupes classes, aucun cycle, aucune arete en arriere. |
| P09 | Flux reseau (schema + matrice) | AFF-071 | ✅ OK | Flux coherents : 29 rôles, 74 flux, schéma + matrice OK. |
| P10 | Handlers <-> notify | AFF-034, AFF-035 | ✅ OK | Tout notify pointe vers un handler du meme role (49 roles). |
| P11 | Syntaxe des playbooks (--syntax-check) | AFF-083 | ✅ OK | playbook: playbooks/proxmox/cloner_vm_debian.yml |
| P12 | Existence des runbooks cites | AFF-010, AFF-011, AFF-012, AFF-083 | ✅ OK | 17/17 runbooks/registres cites presents. |
| P13 | Invariants structurels/doctrinaux | AFF-015, AFF-022, AFF-037, AFF-038, AFF-062 | ✅ OK | LICENSE, socle dossier, pas de couches paralleles, SSH clef-only, nftables off : OK. |
| P14 | Pas de chemin lab/ code en dur | AFF-097 | ✅ OK | Aucun chemin instance/inventories/lab/group_vars code en dur. |
| P15 | Modele public socle valide | AFF-022, AFF-099 | ✅ OK | Modele public socle : domaines/serveurs/applications/bases valides. |
make raser : la seule commande destructive du moteur, avec ses quatre verrous Ajoutee pour rendre la reconstruction from-zero REPETABLE — un test qu'on ne peut jouer qu'une fois n'est pas une recette. Verrous, tous eprouves avant usage : - VMID derives du plan uniquement (le gabarit dore est structurellement exclu) - le NOM doit correspondre : un VMID du plan sous un autre nom fait refuser l'operation ENTIERE. Pas theorique — le 2026-08-07 une VM heritee portait un VMID du plan sous le nom web-frontal-01 et proxmox_kvm rapportait ok. - il faut NOMMER l'ecosysteme (INSTANCE=) : le symlink instance/ peut pointer n'importe ou ; taper le nom distingue le POC de la production. - CONFIRMER=true ; sans lui, inventaire et rien d'autre. Le verrou du nom est le seul qu'on ne peut pas eprouver sur le vrai cluster sans y fabriquer une collision : scripts/tests/test_raser.py l'isole derriere un faux cluster, rattache a P02. Harnais : 31 preuves, 0 sautee. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 14:22:04 -04:00
| P16 | Inventaire Ansible complet (--list) | AFF-030 | ✅ OK | 14 hotes, 31 groupes (inventaire dechiffre et parse). |
identite : « mot de passe oublie » — raccord SMTP derive du plan Le realm portait une politique d'acces complete et aucun moyen d'ecrire a qui que ce soit. Tout oubli remontait donc a l'exploitant, qui n'avait d'autre choix que de manipuler le mot de passe d'autrui. - serveur_keycloak/tasks/courriel-realm.yml : reconcilie smtpServer et resetPasswordAllowed ; hote du relais DERIVE de applications.postfix.hote, et refus explicite si le plan ne declare pas de MTA. - passe par l'API d'administration : kcadm.sh accepte les deux formes -s sur une map, sort en succes et n'ecrit rien (smtpServer reste vide). - amorcage_acces_courriel redevient a declarer : cette adresse designe une personne, hors du systeme qu'on amorce ; une boite interne serait illisible tant qu'on n'a pas l'acces qu'on cherche justement a recuperer. - autorisation.md §6.6 : le mecanisme, ses deux conditions, et l'ecart d'adresse laisse par l'ancien mode READ_ONLY de la federation. Preuve : banniere SMTP lue depuis idm-01, RCPT TO accepte, execute-actions-email declenche, MTA en starttls -> relay=mx.chezlepro.ca status=sent (250). Second deploiement changed=0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 06:08:06 -04:00
| P17 | Tous les modeles valident (registres + underlay) | AFF-022, AFF-099 | ✅ OK | Les 1 modele(s) decouvert(s) valident. |
make raser : la seule commande destructive du moteur, avec ses quatre verrous Ajoutee pour rendre la reconstruction from-zero REPETABLE — un test qu'on ne peut jouer qu'une fois n'est pas une recette. Verrous, tous eprouves avant usage : - VMID derives du plan uniquement (le gabarit dore est structurellement exclu) - le NOM doit correspondre : un VMID du plan sous un autre nom fait refuser l'operation ENTIERE. Pas theorique — le 2026-08-07 une VM heritee portait un VMID du plan sous le nom web-frontal-01 et proxmox_kvm rapportait ok. - il faut NOMMER l'ecosysteme (INSTANCE=) : le symlink instance/ peut pointer n'importe ou ; taper le nom distingue le POC de la production. - CONFIRMER=true ; sans lui, inventaire et rien d'autre. Le verrou du nom est le seul qu'on ne peut pas eprouver sur le vrai cluster sans y fabriquer une collision : scripts/tests/test_raser.py l'isole derriere un faux cluster, rattache a P02. Harnais : 31 preuves, 0 sautee. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 14:22:04 -04:00
| P18 | Gabarit de voute complet | AFF-026 | ✅ OK | Gabarit de voute complet : 25 secret(s) exige(s), tous presents. Voute reelle : 28 cle(s), aucun manque. |
identite : « mot de passe oublie » — raccord SMTP derive du plan Le realm portait une politique d'acces complete et aucun moyen d'ecrire a qui que ce soit. Tout oubli remontait donc a l'exploitant, qui n'avait d'autre choix que de manipuler le mot de passe d'autrui. - serveur_keycloak/tasks/courriel-realm.yml : reconcilie smtpServer et resetPasswordAllowed ; hote du relais DERIVE de applications.postfix.hote, et refus explicite si le plan ne declare pas de MTA. - passe par l'API d'administration : kcadm.sh accepte les deux formes -s sur une map, sort en succes et n'ecrit rien (smtpServer reste vide). - amorcage_acces_courriel redevient a declarer : cette adresse designe une personne, hors du systeme qu'on amorce ; une boite interne serait illisible tant qu'on n'a pas l'acces qu'on cherche justement a recuperer. - autorisation.md §6.6 : le mecanisme, ses deux conditions, et l'ecart d'adresse laisse par l'ancien mode READ_ONLY de la federation. Preuve : banniere SMTP lue depuis idm-01, RCPT TO accepte, execute-actions-email declenche, MTA en starttls -> relay=mx.chezlepro.ca status=sent (250). Second deploiement changed=0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 06:08:06 -04:00
| P19 | Le GUI couvre le schema du plan | AFF-002, AFF-095 | ✅ OK | GUI : les 28 champ(s) des plans reels sont editables (2 plan(s) inspecte(s)), registres toleres : nomenclature. |
| P20 | Adressage 100% derive du seed (aucun stocke) | AFF-001, AFF-003 | ✅ OK | 2 nomenclature(s) : adressage 100% derive du seed index. |
| P21 | Federation : aucun index en collision | AFF-102 | ✅ OK | Federation coherente : 2 instance(s) federee(s), aucun index en collision. |
| P22 | Plan de recette a jour (genere du wiki) | AFF-002 | ✅ OK | Plan de recette à jour (19 sections). |
| P23 | Underlay sans collision avec la plage tenant | AFF-103 | ✅ OK | Underlay conforme : 6 reseau(x), aucune collision avec la plage tenant. |
| P24 | Frontiere nord/sud : acces d'administration declare | AFF-104 | ✅ OK | CONFORME : frontiere nord/sud, 31 regles, 2 routes, admin=10.0.0.0/24,192.168.254.2/32,192.168.255.2/32. |
| P25 | Pare-feu Proxmox : est-ouest intra-tenant derive | AFF-107 | ✅ OK | CONFORME : pare-feu Proxmox, 2 tenant(s), 38 groupe(s), 64 regle(s). |
| P26 | Integrations universelles : aucun hote laisse de cote | AFF-108 | ✅ OK | 14 hote(s) x 4 integration(s) universelle(s) : aucune lacune, aucune recopie (1 exemption(s) derivee(s) du service rendu). |
| P27 | Propriete des intrants : hebergeur et tenant separes | AFF-109 | ✅ OK | 0 cle(s) de cluster chez l'hebergeur, aucune recopiee dans les group_vars du tenant. |
| P28 | Pools Proxmox : un par tenant, sans collision | AFF-110 | ✅ OK | CONFORME : 2 pool(s) Proxmox, 28 VM placee(s), aucun nom ni VMID en collision. |
| P29 | Authentification : chaque role declare sa position | AFF-111 | ✅ OK | 23 role(s) serveur declares (interne-sans-auth 2, ldap-direct 2, sans-auth-humaine 12, socle-identite 2, web-sso 5) ; 2 lacune(s) nommee(s) : serveur_loki, serv |
| P30 | SDN EVPN : zones, VNets et sous-reseaux derives | AFF-112 | ✅ OK | CONFORME : SDN EVPN, 2 zone(s), 12 VNet(s), 12 sous-reseau(x), aucune collision. |
D-71 : PKI et DNS debout avant tout, et la zone inverse manquait Contrainte de l'exploitant apres avoir vu backup-01 et collab-01 crees avant l'AC et le DNS. Ma premiere reponse etait incomplete : un clone est bien inerte, mais un echec a la 12e VM coute 40 minutes sans rien deployer, et le journal donne l'impression que le moteur ignore ses couches. Mesure avant de coder : - enregistrements A : DEJA derives du plan (zone generee depuis hotes_actifs) - zone inverse / PTR : n'existe NULLE PART, aucun role ne touche in-addr.arpa - ordre d'amorcage : aucun, deployer-tout est par couches Le premier point a reduit le travail de moitie — j'allais ecrire un enrolement DNS par hote alors que la zone directe etait deja correcte. Zone inverse derivee du supernet (27.10.in-addr.arpa), PTR issus de la MEME source que les A : pas d'endroit ou elles puissent diverger. Vide si le supernet n'est pas un /16. _amorcer-socle monte l'AC puis le DNS completement avant deployer-tout ; les deux derives de applications.<app>.hote, dans un ordre causal et non alphabetique. Deux exceptions assumees : l'AC s'auto-signe, le DNS pose son propre enregistrement. P10 a attrape un handler que je venais d'inventer (Recharger PowerDNS au lieu de Validate and reload PowerDNS) avant tout deploiement. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 15:29:57 -04:00
| P31 | Documentation : tout ce que le depot FAIT est nomme | — | ✅ OK | 37 scripts expliques et atteignables, 87 cibles make documentees, 54 roles avec README. |
identite : « mot de passe oublie » — raccord SMTP derive du plan Le realm portait une politique d'acces complete et aucun moyen d'ecrire a qui que ce soit. Tout oubli remontait donc a l'exploitant, qui n'avait d'autre choix que de manipuler le mot de passe d'autrui. - serveur_keycloak/tasks/courriel-realm.yml : reconcilie smtpServer et resetPasswordAllowed ; hote du relais DERIVE de applications.postfix.hote, et refus explicite si le plan ne declare pas de MTA. - passe par l'API d'administration : kcadm.sh accepte les deux formes -s sur une map, sort en succes et n'ecrit rien (smtpServer reste vide). - amorcage_acces_courriel redevient a declarer : cette adresse designe une personne, hors du systeme qu'on amorce ; une boite interne serait illisible tant qu'on n'a pas l'acces qu'on cherche justement a recuperer. - autorisation.md §6.6 : le mecanisme, ses deux conditions, et l'ecart d'adresse laisse par l'ancien mode READ_ONLY de la federation. Preuve : banniere SMTP lue depuis idm-01, RCPT TO accepte, execute-actions-email declenche, MTA en starttls -> relay=mx.chezlepro.ca status=sent (250). Second deploiement changed=0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 06:08:06 -04:00
## Couverture des affirmations ✅ du registre
Chaque affirmation ✅ automatisable est couverte par la preuve indiquee ci-dessus.
Les ✅ **structurelles/doctrinales** non rejouables par une commande (ex. AFF-005
`make`=aide, AFF-014 ciblage groupe, AFF-024 `instancier-appliquer`, AFF-051 autorite
d'AGENTS.md, AFF-073/075 gardes `make`, AFF-090 wiki) ont ete verifiees a l'audit ;
elles restent hors du harnais recurrent (rien d'executable a rejouer).
## Declarations d'intention (⚪ invérifiables localement — assumees)
Ces affirmations ne sont pas rejouables hors production ; elles sont **assumees**
comme declarations d'intention, non comme preuves :
- **AFF-036** — « testables avec `--check` autant que possible » : verifiable seulement
contre une flotte vivante.
- **AFF-091** — contenu pedagogique du wiki : affirmations conceptuelles.
- **AFF-096** — « GUI 100 % francais » : revue exhaustive des libelles rendus, non automatisee.
- **AFF-007** — hote d'exemple `web-frontal-01` : placeholder assume.
_Rapport genere le 2026-08-08._
Reference in a new issue Copy permalink