Set-OPS-Public/docs/intrants-communs.md

Intrants communs de l'écosystème

Pour qui : le mainteneur — les valeurs partagées par tout l'écosystème, et qui les possède.

Recensement des intrants communs : les valeurs partagées par tout l'écosystème (par opposition aux valeurs propres à un seul hôte). Objectif : les saisir une fois, depuis un endroit unique, puis les laisser se dériver ou se propager.

Concept lié : meta-classe.md (une définition instancie la flotte) et dimensionnement-ressources.md.

1. Recensement par domaine

A. Identité de l'instance — group_vars/<env>/all.yml

• domaine_interne — domaine DNS interne (ex. chezlepro.internal). Keystone : zones DNS, FQDN, base DN LDAP, expéditeurs courriel, URL AC en dérivent.
• fuseau_horaire — fuseau (ex. America/Toronto).
• setops_plan_dir — chemin du plan.

B. Réseau & nomenclature — plan/nomenclature.yml

• index — le seed, et le seul champ d'adressage. Supernet, sous-réseaux, passerelles, VLAN et VMID en dérivent ; la preuve P20 refuse qu'on les y écrive.
• cidr_hote, reservations, categories (libellés de zones), fonctions (catégorie + service).

Ce paragraphe listait supernet comme un intrant de la nomenclature jusqu'au 2026-09-06. C'est exactement ce que P20 interdit : un adressage stocké est un adressage qui peut contredire celui qu'on dérive.

C. Hyperviseur Proxmox — group_vars/proxmox.yml

• proxmox_api_host, proxmox_api_user, proxmox_api_port, proxmox_validate_certs.
• 🔒 proxmox_api_token_id, proxmox_api_token_secret — dans la voûte unique de l'instance, group_vars/all/vault.yml. proxmox.vault.yml n'est plus lue (retirée le 2026-08-03) : 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. Cf. docs/config-proxmox.md.
• Golden template : proxmox_clone_vmid_modele, proxmox_clone_source_nom.
• Placement par défaut : proxmox_clone_noeud, proxmox_clone_stockage, proxmox_clone_pont, format, complet, timeout, disque, interface, démarrer.

D. Identité initiale des VM — group_vars/modeles_vm.yml, creer-vm

• Clé publique SSH (cloud-init) — accès admin de toute la flotte.
• Compte technique ansible (sudo_ansible_admin_user) + sudo NOPASSWD, ciuser.
• Politiques SSH communes (port, password auth off, root login off, grace/auth tries).

E. Socle durci commun — group_vars/modeles_vm.yml

nftables baseline · fail2ban SSH · auditd · AppArmor · sysctl · unattended-upgrades · journald (rétention) · core_dumps · systemd_ssh_auto.

F. Endpoints des services centraux (les rôles client_* en dérivent)

• DNS interne : plancher /etc/hosts (hosts_statiques) + PowerDNS (autoritatif) + serveur_resolveur (LE récursif du tenant), désigné sur chaque nœud par client_resolveur — intégration universelle, pas opt-in.
• AC/PKI (client_pki_ca_url → infra-pki, provisioner).
• IdM/LDAP : annuaire résolu par resoudre_annuaire (hôte + base DN dérivés du domaine).
• Relais courriel (client_smtp_relais → edge-mta, MTA Postfix, port 25).
• Métriques (node_exporter :9100).
• Journaux (client_journal_loki_url → obs).
• Temps (NTP) : implicite (pool Debian par défaut — aucun intrant configuré).

G. Dépôts APT tiers communs

• Smallstep (step-cli) — client_pki ↔ serveur_step_ca.
• Grafana (alloy/loki/grafana) — client_journal ↔ serveur_loki/serveur_grafana.

H. Secrets Vault communs 🔒 — voûte unique group_vars/all/vault.yml

Tous les secrets de l'instance dans un seul fichier chiffré par environnement (inventories/<env>/group_vars/all/vault.yml), gabarit exemples/vault.exemple.yml. Un mot de passe, un endroit. Édité via ansible-vault edit (jamais par le GUI). La liste ne s'écrit pas ici. Elle se recense, depuis le plan, les rôles des groupes actifs et les group_vars :

python3 scripts/voute.py lister     # chaque secret exigé + d'où vient l'exigence
make prouver                        # P18 : le gabarit les couvre-t-il tous ?

C'est la même source que le rappel « Secrets attendus » du panneau d'intrants. Trois copies manuelles de cette liste ont existé et toutes ont divergé — elles annonçaient vault_ldap_sssd, qu'aucun rôle ne consomme, et vault_step_ca_fingerprint, que client_pki dérive à chaud depuis l'AC plutôt que de la lire.

Mot de passe du Vault lui-même : saisi au déploiement.

I. Exposition publique — plan/domaines.yml

domaines publics, edge, autorité DNS, FQDN exposés.

2. Classification proposée : constante vs défaut surchargeable

Proposition à valider. « Constante » = une seule valeur, pas de surcharge (diverger casserait le modèle). « Défaut surchargeable » = valeur globale qui ressurgit comme défaut là où l'intrant réapparaît (hôte / groupe / application).

Intrant	Classe	Surcharge où ?
domaine_interne	Constante	—
Nomenclature (index, CIDR d'hôte, catégories, fonctions)	Constante	— (le seed est la loi ; l'adressage en dérive)
Accès Proxmox (API host/user/port/token)	Constante	— (un seul cluster)
Golden template (vmid_modele, source_nom)	Constante	—
Secrets Vault	Constante 🔒	— (gérés à part, jamais en clair)
fuseau_horaire	Défaut	par hôte (rare)
proxmox_clone_noeud / stockage / pont	Défaut	par hôte (serveurs.yml)
DNS internes (plancher /etc/hosts + PowerDNS)	Défaut	par hôte / groupe
Politiques durcissement (SSH, nftables, fail2ban, journald…)	Défaut	par hôte / groupe
Relais SMTP, TLS internes	Défaut	par hôte / groupe
ciuser, compte ansible	Défaut	rarement surchargé

3. Saisie unique dans le GUI (cible)

Un panneau « Intrants de base » dans le GUI :

• édite les constantes et les défauts au même endroit ;
• pour un défaut, la valeur globale apparaît pré-remplie (et signalée comme « héritée ») là où l'intrant réapparaît dans le plan, surchargeable sur place ;
• les secrets ne sont jamais stockés en clair par le GUI (cf. §H) — il en gère au plus les références, l'édition réelle restant côté Vault.

Persistance : les fichiers de l'instance (group_vars/all/10-intrants.yml — forme dossier ; la forme plate group_vars/all.yml reste lue en compatibilité —, proxmox.yml, modeles_vm.yml, plan/nomenclature.yml). À détailler dans la note de conception de la fonctionnalité GUI.

4. Incohérences repérées — soldées

Les deux écarts que cette section signalait n'existent plus (vérifié le 2026-09-06), et le modèle « deux environnements » qui les portait non plus :

• fuseau_horaire défini en lab seulement, absent de production — il est dans group_vars/all/10-intrants.yml (America/Toronto), avec domaine_interne.
• group_vars/serveur_debian.yml référencé mais absent — plus aucune référence.

Il n'y a plus d'« environnements ». Ce document parle de <env> par endroits : c'est le vocabulaire d'avant la séparation par instance. Une instance = un dépôt, avec un inventaire (le moteur en résout le nom, cf. plan-et-generation.md). « Lab » et « production » ne sont pas deux environnements d'un même écosystème : ce sont deux écosystèmes, chacun avec son plan, son inventaire et sa voûte.