Set-OPS-Public/docs/config-proxmox.md
Daniel Allaire 835f8ab6d0 Mise en conformité prouvable : registre d'affirmations + make prouver
Le dépôt fait / explique / prouve ce qu'il affirme, vérifiable en une commande.

- Phase 1 : docs/audit/affirmations.md — 54 affirmations publiques tracées vers
  une commande de preuve et un statut (/🟡//).
- Phase 2 : CLAUDE.md réduit à un pointeur mince ; contradiction SSH levée (le
  code applique déjà PasswordAuthentication no + AuthenticationMethods publickey,
  conforme à AGENTS.md) ; section AGENTS « Codex » → « agents IA ».
- Phase 3 : parcours démarrage réparé (QUICKSTART renvoyait à un modèle absent,
  chemins de voûte faux, commandes make périmées) ; make verifier vert
  (ansible-lint 33 → 0 : site.yml généré nommé, pipefail, name[template]) ;
  voûte Proxmox unifiée lue par le clonage (all/vault.yml).
- Phase 4 : make prouver → docs/audit/preuve-<date>.md, harnais rejouable qui
  rappelle l'outillage existant (aucune validation réimplémentée).
- Phase 5 : parcours QUICKSTART prouvé hors-ligne sur le socle ; modèle socle
  rendu valide (autorite interne → auto-heberge) ; split-brain d'inventaire
  corrigé (repli sur le répertoire existant, pas principal/).

make prouver : 15 OK, 0 échec, 1 sautée (voûte). ansible-lint : 0 failure.
Écarts découverts en cours de traitement (AFF-097..100) : tous résolus.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-20 19:53:18 -04:00

114 lines
6.7 KiB
Markdown

# `make config` — référence des paramètres Proxmox
`make config` lance `scripts/config_proxmox.py`, l'assistant interactif qui écrit
la connexion au cluster Proxmox et les valeurs de clonage par défaut. Il pose
**16 paramètres non sensibles** puis propose de saisir les **secrets API**.
- Non sensibles → `instance/inventories/production/group_vars/proxmox.yml`
- Secrets → **voûte unique** `instance/inventories/production/group_vars/all/vault.yml`
(chiffrée par `ansible-vault`), qui contient **tous** les secrets de l'instance
(token Proxmox + `vault_*`). Voir [§4](#4-secrets-de-linstance-).
À chaque invite, la valeur courante (ou le défaut) est affichée entre crochets :
**appuyer sur Entrée conserve cette valeur**. On peut donc relancer `make config`
sans tout retaper.
> Ces paramètres sont des **intrants communs** de l'écosystème (cf.
> [`intrants-communs.md`](intrants-communs.md) §C). L'accès au cluster et le golden
> template sont des **constantes** ; le placement par défaut est **surchargeable
> par hôte** dans `instance/plan/serveurs.yml`.
---
## 1. Accès au cluster Proxmox *(constantes — un seul cluster)*
| Invite | Variable | Défaut | Sens / quoi saisir |
| --- | --- | --- | --- |
| Hôte API Proxmox | `proxmox_api_host` | *(vide)* | Nom DNS ou IP du nœud qui répond à l'API. Ex. `asgard`. |
| Utilisateur API Proxmox | `proxmox_api_user` | *(vide)* | Utilisateur **avec le realm**. Ex. `ansible@pve` (realm PVE) ou `root@pam`. |
| Port API Proxmox | `proxmox_api_port` | *(vide)* | Port HTTPS de l'API. Quasi toujours `8006`. |
| Valider les certificats TLS | `proxmox_validate_certs` | `non` | `oui` si le cluster a un certificat de confiance ; `non` pour un certificat auto-signé (cas usuel en lab). |
## 2. Golden template *(constantes — le modèle cloné)*
| Invite | Variable | Défaut | Sens / quoi saisir |
| --- | --- | --- | --- |
| VMID du modèle Debian 13 | `proxmox_clone_vmid_modele` | `9000` | VMID de la VM-modèle existante à cloner pour chaque nouvelle VM. |
| Nom logique du modèle | `proxmox_clone_source_nom` | `modele-debian13` | Nom de référence du template (lisibilité ; doit correspondre au modèle). |
> Le golden template est l'**actif central** : il est cloné pour chaque VM, jamais
> jeté ni reconstruit à la légère.
## 3. Placement par défaut des clones *(défauts surchargeables par hôte)*
Ces valeurs s'appliquent à toute VM clonée, **sauf** si l'hôte les surcharge dans
`instance/plan/serveurs.yml`.
| Invite | Variable | Défaut | Sens / quoi saisir |
| --- | --- | --- | --- |
| Nœud Proxmox par défaut | `proxmox_clone_noeud` | *(vide)* | Nœud du cluster où créer la VM. Ex. `asgard`. |
| Stockage Proxmox par défaut | `proxmox_clone_stockage` | *(vide)* | Datastore qui héberge le disque. Ex. `local-zfs`, `TrueNAS`. |
| Pont Proxmox | `proxmox_clone_pont` | `vmbr0` | Bridge réseau de la NIC. Ex. `vmbr0`, `vmbr1`. |
| Format disque par défaut | `proxmox_clone_format` | *(vide)* | `qcow2`, `raw`, … ou **vide** pour laisser le stockage décider (recommandé : ZFS/LVM imposent leur format). |
| Clone complet | `proxmox_clone_complet` | `oui` | `oui` = clone **indépendant** (autonome) ; `non` = clone **lié** (dépend du modèle, plus léger mais fragile). Garder `oui`. |
| Timeout opérations Proxmox | `proxmox_clone_timeout` | `600` | Secondes avant d'abandonner une opération longue (clone, redimensionnement). |
| Disque principal | `proxmox_clone_disque` | `scsi0` | Bus + index du disque système. `scsi0` est le standard Set-OPS. |
| Interface réseau | `proxmox_clone_interface` | `net0` | Identifiant de la NIC virtuelle. |
| Pare-feu interface Proxmox | `proxmox_clone_parefeu_interface` | `non` | Active le pare-feu Proxmox **au niveau de la NIC**. Laisser `non` : le filtrage se fait dans l'invité (nftables), pas chez l'hyperviseur. |
| Démarrer le clone après création | `proxmox_clone_demarrer` | `oui` | `oui` = booter la VM dès la création (nécessaire pour qu'Ansible la joigne ensuite). |
## 4. Secrets de l'instance 🔒 *(voûte unique)*
Tous les secrets de l'instance vivent dans **une seule voûte chiffrée par
environnement** : `instance/inventories/<env>/group_vars/all/vault.yml`. Un seul
fichier, un seul mot de passe — fini les voûtes éparpillées. Gabarit committé :
[`exemples/vault.exemple.yml`](../exemples/vault.exemple.yml) (token Proxmox +
17 clés `vault_*` pour PKI, LDAP/SSO, bases, forge, observabilité).
L'assistant demande « Configurer la voûte de secrets maintenant ». Si `oui` :
| Invite | Variable | Défaut | Sens / quoi saisir |
| --- | --- | --- | --- |
| Token ID Proxmox | `proxmox_api_token_id` | `set-ops` | Identifiant du **token API** créé côté Proxmox. |
| Token secret Proxmox | `proxmox_api_token_secret` | *(aucun)* | Secret du token. **Saisie masquée**, écrit dans la voûte chiffrée. |
- Si la voûte **existe déjà**, l'assistant ouvre directement `ansible-vault edit`
(aucune re-saisie en clair).
- Si elle **n'existe pas**, l'assistant la **sème depuis le gabarit** (toutes les
clés présentes, vides), y place le token, puis la chiffre. On renseigne ensuite
les autres secrets avec `ansible-vault edit …/all/vault.yml`.
- Ces secrets ne transitent **jamais** par le GUI ni par aucun fichier en clair ;
le GUI n'en affiche que les **noms** (panneau « Intrants »).
### Migration depuis l'ancienne `proxmox.vault.yml`
Si tu as déjà une `proxmox.vault.yml`, déplace son contenu dans la voûte unique :
```bash
cd instance/inventories/production/group_vars
cp ../../../../exemples/vault.exemple.yml all/vault.yml
ansible-vault view proxmox.vault.yml # relève token_id + secret
ansible-vault edit all/vault.yml # colle-les, renseigne le reste
ansible-vault encrypt all/vault.yml # si pas déjà chiffrée
git rm --cached --ignore-unmatch proxmox.vault.yml 2>/dev/null; rm proxmox.vault.yml proxmox.vault.yml.example
```
---
## Comment créer le token API côté Proxmox
Dans l'interface Proxmox (ou en CLI `pveum`) :
1. Créer l'utilisateur API (ex. `ansible@pve`) et lui donner les droits requis
(rôle avec `VM.Allocate`, `VM.Clone`, `VM.Config.*`, `Datastore.AllocateSpace`,
`SDN.Use`/réseau selon le cluster).
2. Créer un **token API** pour cet utilisateur → noter le **Token ID** et le
**secret** (affiché une seule fois).
3. Renseigner Token ID + secret dans `make config`.
## Voir aussi
- [`intrants-communs.md`](intrants-communs.md) — tous les intrants communs de l'écosystème.
- [`nomenclature-vm.md`](nomenclature-vm.md) — réseau, VLAN, fonctions.
- [`vm-lifecycle.md`](vm-lifecycle.md) — cycle de vie d'une VM (création → conformité).
- `make` — liste des cibles (l'aide est la cible par défaut).