diff --git a/README.md b/README.md index f93adcd..a77edd3 100644 --- a/README.md +++ b/README.md @@ -72,13 +72,17 @@ Les dépôts vivent sous l'organisation `genome` : |---|---| | `set-ops-public` | **oui** — toutes les 8 h | | `ops-patient0` | **oui** — toutes les 8 h | -| `site-chezlepro` | non — figé au poussage | -| `set-ops-modeles` | non — figé au poussage | +| `site-chezlepro` | **oui** — toutes les 8 h, authentifié | +| `set-ops-modeles` | **oui** — toutes les 8 h, authentifié | | `ops-chezlepro` | non, et privé — le plan d'un tenant voisin, sans usage ici | -Les deux miroirs suivent `forge.alliance-boreale.ca`. Les trois autres attendent un jeton -amont en **lecture seule** : un jeton capable d'écrire chez le parent inverserait le sens -de la filiation, et ne sera pas posé ici. +Les quatre miroirs suivent `forge.alliance-boreale.ca`. Les deux dépôts privés sont lus +par un jeton de **lecture seule** (`vault_miroir_amont`, portée unique +`read:repository`) : un jeton capable d'écrire chez le parent inverserait le sens de la +filiation — l'enfant pourrait réécrire le génome dont il est issu. + +Les quatre restent **lisibles** sur la forge de patient 0, et c'est ainsi que son poste +d'exploitation les clone : en anonyme, sans détenir aucun justificatif. L'étiquette signée `v2026.08.21` a traversé le miroir intacte — la provenance reste vérifiable depuis l'enfant. @@ -139,7 +143,6 @@ ses VLAN n'auraient existé nulle part. ## Ce qui reste devant -- [ ] **Les trois miroirs privés**, dès qu'un jeton amont en lecture seule existe. - [ ] **Décider où il vit.** Sur `asgard`, la perte du cluster emporte patient 0 *et* Chezlepro d'un coup. Ailleurs, la famille survit à la perte du cluster. Le déménagement tient en quatre valeurs (`group_vars/proxmox.yml`) et un symlink. diff --git a/inventories/production/group_vars/all/vault.yml.example b/inventories/production/group_vars/all/vault.yml.example index 5304cb1..1a45a19 100644 --- a/inventories/production/group_vars/all/vault.yml.example +++ b/inventories/production/group_vars/all/vault.yml.example @@ -43,9 +43,16 @@ vault_sysadmin_amorcage: "" # role amorcage_acces (playbook # Ces deux-la ne commencent pas par `vault_` et echappent donc au reperage automatique : # c'est P18 qui les exige nommement. Ils ouvrent l'API Proxmox pour cloner les VM. # -# A CREER DANS PROXMOX, propre a patient 0 : Datacenter > Permissions > API Tokens. -# Un jeton PAR TENANT, revocable seul — recopier celui d'un autre tenant reviendrait a -# leur donner la meme clef, et a ne plus pouvoir en retirer un sans retirer l'autre. -# Les poser ensuite : ansible-vault edit inventories/production/group_vars/all/vault.yml -proxmox_api_token_id: "" -proxmox_api_token_secret: "" +# LES JETONS PROXMOX NE SONT PLUS ICI (separation des voutes, 2026-08-22). +# +# Le jeton d'API du cluster appartient a l'HEBERGEUR, pas a l'organisation hebergee. Il +# vit desormais dans la voute du site — `SITE-Chezlepro/underlay.vault.yml` — avec la cle +# de la frontiere. Recopie dans la voute de chaque tenant, il ne pouvait plus etre revoque +# isolement : retirer l'acces d'un locataire revenait a le retirer a tous. +# +# `proxmox_api.voute()` lit la voute du tenant PUIS celle de l'underlay, et c'est celle de +# l'hebergeur qui fait foi quand les deux portent la cle. Un jeton pose ici serait donc +# ignore — mieux vaut ne pas le poser du tout que croire qu'il sert. +# +# Constate le 2026-08-23 : ce gabarit reclamait encore `proxmox_api_token_id` et +# `proxmox_api_token_secret` d'un tenant qui ne doit pas les detenir.