Set-OPS-Public/docs/integrations-vm.md

Intégrations des VM

Pour qui : le mainteneur qui ajoute une intégration à toutes les VM.

Politique : le défaut est « oui », l'exception se justifie

Une intégration est de l'un des deux genres, et ils ne se déclarent pas au même endroit.

Universelle — métriques, journaux, PKI, résolution et source d'artefacts (les cinq qui portent universelle: true). Il n'y a aucun choix de cible : un seul Prometheus, un seul Loki, une seule AC, un seul résolveur, un seul cache. Elle est déclarée une fois, par le rôle, dans roles/<role>/meta/integration.yml, et tout hôte la reçoit :

integration:
  universelle: true
  raison: "Tout hôte est mesuré. Une machine hors supervision tombe sans que personne ne l'apprenne."
  sauf_role: serveur_step_ca   # facultatif — voir « exemptions »

Facultative — client_backup et client_smtp. Là il y a un vrai choix, et il se déclare par serveur, dans plan/serveurs.yml : integrations.

client_resolveur a changé de camp le 2026-08-24, et ce document l'annonçait encore facultatif. Il posait alors un Unbound sur chaque VM — un vrai coût, donc un vrai choix. Il n'installe plus rien : il écrit /etc/resolv.conf pour désigner le résolveur du tenant. Son intégration est devenue universelle, sans aucune exemption — pas même l'hôte qui porte le résolveur : il se sert lui-même, et l'exempter reviendrait à dire que le résolveur ne se fait pas confiance. Une machine restée sur la résolution d'amorçage envoie chacune de ses questions dehors, sans que rien ne le signale.

Pourquoi cette inversion. Le plan portait 57 lignes d'intégration écrites à la main. 28 d'entre elles disaient oui à quelque chose de vrai pour tous les hôtes — elles n'existaient donc que pour être oubliées, et quatre l'avaient été : deux serveurs n'étaient ni supervisés, ni journalisés, ni certifiés. Personne ne l'aurait su, puisqu'une machine non supervisée ne proteste pas. Depuis, oublier est impossible : il faut exempter, et dire pourquoi.

Le plan refuse désormais une recopie (valider_serveurs). Deux sources finiraient par diverger, et surtout : l'absence de client_metrique en face d'un serveur se lirait « non supervisé » alors qu'il l'est.

Les exemptions se dérivent du service rendu

Une exemption ne nomme jamais un hôte. Elle nomme le rôle serveur dont la présence la justifie : sauf_role: serveur_step_ca retire client_pki à l'hôte qui est l'AC — elle ne s'enrôle pas auprès d'elle-même. Déplacez step-ca sur une autre machine et l'exemption suit, sans qu'on y touche.

P26 garde les deux côtés : aucun hôte sans intégration universelle, aucune recopie dans le plan.

Ce que le panneau montre

Dans la fiche d'un serveur, les universelles apparaissent en ✓ non décochables, les exemptions barrées, avec leur raison en infobulle. Sans cet affichage, un plan devenu silencieux se lirait comme une flotte non supervisée — l'inverse exact de la vérité.

La vue Intégrations donne l'autre axe : une matrice serveurs × intégrations. Colonnes ✓ pour la politique, — barré pour les exemptions, cases à cocher pour les facultatives — éditables sur place, puis Sauvegarder. La ligne couverture affiche n/N par colonne.

Elle ne juge pas : 7/14 sur client_backup peut être exactement juste. Elle rend le motif visible, ce que quatorze fiches consultées une par une ne faisaient pas — c'est précisément pour ça que le trou de Chezlepro est resté invisible jusqu'à ce qu'un devis de pare-feu l'énumère.

---

Séparation

Template Debian 13 Proxmox : socle commun minimal
Cloud-init                 : identité initiale du clone
Set-OPS + Ansible          : configuration réelle du serveur

Le template ne doit pas être modifié pour chaque nouveau serveur. Les intégrations sont appliquées après clonage selon les groupes d'inventaire et les playbooks dédiés.

Domaines prévus

DNS interne        : PowerDNS, résolveurs, enregistrements applicatifs
PKI interne        : step-ca, ACME, confiance CA locale
Identité           : LDAP, SSSD, Keycloak/OIDC selon le besoin
Supervision        : Icinga2 agent ou checks distants
Métriques          : Prometheus node_exporter
Visualisation      : Grafana côté plateforme centrale

Principes Ansible

• Un rôle d'intégration doit être inoffensif hors de son groupe : c'est l'appartenance au groupe qui l'active, jamais un drapeau recopié. (Ce principe disait autrefois « désactivé par défaut », à l'époque où les serveurs centraux n'existaient pas ; depuis, trois intégrations sont universelles — voir §Politique.)
• Chaque variable de rôle doit utiliser le préfixe du rôle.
• Les secrets ne doivent jamais être stockés en clair dans le dépôt.
• Un rôle ne doit pas échouer si son intégration est désactivée.
• Les playbooks applicatifs doivent être appliqués sur les clones, pas sur le template.
• Les opérations pouvant couper l'accès réseau ou SSH doivent exiger une confirmation explicite.

Ordre logique de construction

1. DNS interne.
2. PKI interne et confiance CA.
3. Identité système et applicative.
4. Supervision et métriques.
5. Visualisation et alerting.

Cet ordre reste indicatif. Les rôles doivent rester découplés pour permettre une adoption progressive.