History

Daniel Allaire 90228cb55e supervision : la sonde se declare dans le role, comme le flux LE CONSTAT. 39 roles declarent leurs flux, 32 leur empreinte, 32 leur authentification — tous derives. Et 19 groupes sur 19 declaraient une surveillance en prose que RIEN n executait ; Icinga en surveillait deux. La carte disait ce qui etait surveille, et personne ne surveillait. LE MECANISME. Un role declare ses sondes dans meta/supervision.yml et depose lui-meme son script dans /usr/local/lib/setops/sondes/. Le porteur client_sante les fait toutes tourner et pousse un resultat passif par sonde, sans savoir ce qu elles mesurent. serveur_icinga derive les objets Service ET le filtre de permission d API des memes declarations. Ajouter une sonde ne demande de toucher ni au porteur ni a Icinga. PREMIERE SONDE : client_pki/certificat. Heures restantes sur le certificat reellement pose, chaine verifiee, et empreinte SERVIE comparee au disque quand un service le consomme. 14/14 au tenant, 7/7 au site. QUATRE OBSTACLES, ET TROIS SONT LA MEME LECON. La sonde a rendu 14/14 en CRITIQUE sur une PKI saine : openssl verify -CAfile racine ne trouve pas l intermediaire qui signe nos certificats. step certificate verify, lui, repond VALIDE. Deployee au site, elle a rendu 5/7 : le seuil d avertissement (12 h) etait AU-DESSUS du point de renouvellement (8 h, le tiers restant). Elle criait avant que le mecanisme ne soit cense agir. Seuils ramenes a 6 h et 3 h. Un seuil se DERIVE du moment ou le mecanisme surveille agit. Une alarme toujours allumee ne vaut pas mieux qu une alarme jamais allumee : elle apprend a ne plus regarder. Une sonde se prouve DEUX FOIS, verte sur le sain et rouge sur le casse. Le filtre d API etait ecrit avant la lecture des declarations : les services auraient existe et Icinga aurait refuse leurs resultats. Et mon controle negatif a casse un service reel : substituer le certificat d hote a fait propager un cert sans sa clef vers node_exporter. Un controle negatif se fait sur une COPIE. P64 tient les deux bouts : declaree sans etre deposee, ou deposee sans etre declaree. Trois controles negatifs rejoues. make prouver : CONFORME, 64 OK, 0 echec, 0 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q		2026-09-09 21:45:49 -04:00
..
defaults	supervision : la sonde se declare dans le role, comme le flux	2026-09-09 21:45:49 -04:00
handlers	deploiement : deux attentes de premier demarrage, et trois defauts leves	2026-08-07 09:30:48 -04:00
meta	supervision : la sonde se declare dans le role, comme le flux	2026-09-09 21:45:49 -04:00
tasks	supervision : la sonde se declare dans le role, comme le flux	2026-09-09 21:45:49 -04:00
templates	supervision : la sonde se declare dans le role, comme le flux	2026-09-09 21:45:49 -04:00
README.md	client_pki : l'empreinte du root CA n'est pas un secret de voûte	2026-08-01 22:37:27 -04:00

README.md

client_pki

Intégration cliente PKI / identité machine : chaque hôte fait confiance à l'AC interne (serveur_step_ca), obtient son propre certificat et le renouvelle automatiquement.

Rôle

Installe step-cli (dépôt apt Smallstep).
Confiance : step ca bootstrap --install → installe la racine de l'AC dans le magasin de confiance système (l'hôte fait confiance au TLS interne réel).
Certificat d'hôte : step ca certificate <fqdn> via le provisioner.
Renouvellement automatique : unités systemd officielles cert-renewer@.{service,timer} (vérifie/renouvelle toutes les 15 min, recharge le service consommateur s'il existe).

« Chaque hôte authentifiable »

Après ce rôle, l'hôte possède une identité machine vérifiable : un certificat émis par l'AC interne, renouvelé sans intervention. Les services peuvent l'utiliser pour du TLS / mTLS interne.

Secrets requis (Vault)

client_pki_provisioner_password: "{{ vault_step_ca_provisioner_password }}"  # partage avec serveur_step_ca

Un seul — et l'empreinte racine n'en fait pas partie.

L'empreinte du root CA n'est pas un intrant

Elle est dérivée à chaud depuis l'autorité (step certificate fingerprint exécuté sur serveur_step_ca, en delegate_to), et non lue depuis la voûte. La raison : un from-zero régénère l'AC, donc son empreinte change. Une empreinte figée en voûte serait périmée dès la première reconstruction — et une empreinte périmée fait échouer le bootstrap de chaque hôte, sans que rien n'indique pourquoi.

Si l'AC est injoignable ou pas encore déployée, un assert échoue avec un message clair plutôt que de laisser passer une empreinte vide — ce qui reviendrait à faire confiance à n'importe quelle autorité au premier contact.

Pour épingler explicitement une empreinte (AC externe, migration) : client_pki_ca_fingerprint_override.

Variables principales

Variable	Défaut	Rôle
`client_pki_ca_url`	`https://infra-pki-01.exemple.internal:8443`	URL de l'AC
`client_pki_provisioner`	`admin@exemple.internal`	Provisioner émetteur
`client_pki_nom_cert`	FQDN de l'hôte	Nom du certificat

Notes / sécurité

Émission via le provisioner JWK (mot de passe partagé) : tout hôte avec ce secret peut émettre des certificats. Acceptable en interne ; pour durcir, basculer vers ACME ou des jetons à usage unique par hôte (phase ultérieure).
Pour qu'un service (nginx, keycloak…) recharge automatiquement après renouvellement, nommer son certificat d'après le service (instance cert-renewer@<service>).

Prérequis

Dépendance client_pki requiert serveur_step_ca actif (déjà dans docs/dependances-groupes.yml).
Réseau vers l'AC (:8443).