Daniel Allaire
4dd3d46412
Reconnaissance en lecture seule de l'API du cluster, avec le jeton de la voûte.
Trois valeurs devinées étaient fausses, et deux défauts bloquants sont apparus.
Corrigé d'après le cluster
- stockages : truenas-dbsql manquait ; le catalogue ne garde que ceux qui
portent `images` (PBS, cephFS, local et truenas iSCSI n'accueillent pas de
disque de VM) ;
- ponts : vmbr0 avait été omis, et l'uniformité sur les trois nœuds n'avait pas
été vérifiée — un pont partiel empêche la VM de démarrer sur certains nœuds.
Pools
Chezlepro-17 et Technolibre-11 créés, dérivés comme le reste. Les pools
Env.Tenant antérieurs (Prod.Chezlepro, Lab.KBR...) sont l'ancien monde : on n'y
touche pas et on n'y verse pas la flotte générée. Diff réel : 2 pools ajoutés,
0 retiré, 1 VM sur 38 déplacée — infra-pki-01, qui n'avait aucun pool.
Défaut bloquant : make creer-vm aurait échoué en 401
proxmoxer recompose `utilisateur!nom` à partir d'api_user et d'api_token_id. La
voûte stocke la forme complète, que les playbooks passaient telle quelle, d'où
un 401 muet — alors que le même jeton fonctionne en curl. Mesuré des deux côtés
avec un module en lecture seule : forme complète = 401, forme courte = OK.
Normalisation par split('!') | last, qui accepte les deux écritures.
Reliquat proxmox.vault.yml supprimé
Toléré « en compatibilité », il restait le seul porteur du jeton chez
Technolibre — et comme *.vault.yml est gitignoré, ce jeton ne voyageait avec
aucun dépôt : une voûte unique (D-19) qui ne l'était pas. Migration faite en
mémoire, avec relecture et aller-retour de chiffrement vérifiés avant écriture ;
fichier supprimé, listes de chargement des playbooks nettoyées, validé par un
appel API réel ne chargeant que all/vault.yml.
La garde qui manquait
voute.py verifier ne comparait que le gabarit — il disait « complet » pendant
qu'un secret vivait ailleurs. Il contrôle maintenant aussi la voûte réelle quand
ANSIBLE_VAULT_PASSWORD_FILE la rend déchiffrable : noms de clés seulement,
jamais de valeur, et vérification sautée sans mot de passe.
Elle a trouvé un second trou dès son premier passage : la voûte réelle de
Technolibre n'a ni vault_nextcloud_admin ni vault_nextcloud_oidc, que le plan
exige. Non corrigé — générer ces secrets est une décision, et celui d'OIDC doit
correspondre à ce que Keycloak connaîtra.
27 preuves OK. --syntax-check et ansible-lint (production) sur les playbooks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
128 lines
7.5 KiB
Markdown
128 lines
7.5 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, côté **tenant** (golden template, défauts de placement)
|
|
→ `instance/inventories/*/group_vars/proxmox.yml`
|
|
- Non sensibles, côté **hébergeur** (API du cluster, nœuds, stockages, ponts)
|
|
→ `<dépôt de l'hébergeur>/proxmox-hebergeur.yml`, à côté d'`underlay.yml`.
|
|
Le chemin se **dérive** du symlink qui désigne déjà l'hébergeur — rien de nouveau
|
|
n'est déclaré. Sans underlay monté, tout retombe dans le fichier du tenant et
|
|
`make config` fonctionne comme avant.
|
|
- 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 »).
|
|
|
|
### `proxmox.vault.yml` n'est plus lue (retirée le 2026-08-03)
|
|
|
|
Les playbooks ne chargent plus ce fichier. Tolérée « en compatibilité », elle était
|
|
restée le **seul** porteur du jeton chez un tenant — et comme `*.vault.yml` est
|
|
gitignoré, ce jeton ne voyageait avec aucun dépôt. Une voûte unique qui ne l'était pas.
|
|
|
|
Si tu en as encore une :
|
|
|
|
```bash
|
|
cd instance/inventories/<env>/group_vars
|
|
ansible-vault view proxmox.vault.yml # relève token_id + secret
|
|
ansible-vault edit all/vault.yml # colle-les
|
|
rm proxmox.vault.yml proxmox.vault.yml.example
|
|
python3 ../../../../scripts/voute.py verifier # confirme : plus rien ne manque
|
|
```
|
|
|
|
> **Le jeton se stocke tel que Proxmox l'affiche** (`utilisateur@realm!nom`). Les
|
|
> playbooks n'en gardent que la partie après `!` : `proxmoxer` recompose l'identifiant
|
|
> à partir d'`api_user`, et lui passer la forme complète produit un **401 muet** —
|
|
> alors que le même jeton fonctionne en `curl`. Les deux écritures sont acceptées.
|
|
|
|
---
|
|
|
|
## 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).
|