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
49 lines
2.6 KiB
Django/Jinja
49 lines
2.6 KiB
Django/Jinja
/*
|
|
* Gere par Set-OPS (role serveur_icinga). Ne pas editer a la main.
|
|
*
|
|
* Compte d'API par lequel un NOEUD depose ses resultats passifs.
|
|
*
|
|
* IL S'APPELLE ENCORE `setops-depot` (2026-09-09) : il servait d'abord au seul rapport de
|
|
* sauvegarde. Il porte desormais aussi le rapport de SANTE — un second compte serait plus
|
|
* pur, un secret par usage, mais exigerait une clef de voute de plus dans chaque
|
|
* ecosysteme, donc un geste manuel a chaque nouvel ecosysteme, pour une portee identique.
|
|
* Le renommer churnerait les voutes sans rien gagner. Le filtre ci-dessous reste etroit :
|
|
* trois noms de service, et aucun autre pouvoir.
|
|
* Portee minimale : uniquement `actions/process-check-result`, et uniquement sur les
|
|
* services de sauvegarde. Ce compte ne peut ni lire la configuration, ni agir ailleurs.
|
|
*/
|
|
object ApiUser "{{ serveur_icinga_api_utilisateur }}" {
|
|
password = "{{ serveur_icinga_api_motdepasse }}"
|
|
permissions = [
|
|
{
|
|
permission = "actions/process-check-result"
|
|
{#
|
|
DEUX FORMES DE NOM, PARCE QU'IL Y A DEUX MODELES (2026-09-02).
|
|
|
|
« sauvegarde: <noeud> » — l'ecosysteme a son propre depot, qui rapporte pour
|
|
tout le monde : les services vivent sur SON hote, le nom doit donc dire de quel
|
|
noeud on parle.
|
|
|
|
« sauvegarde » — l'ecosysteme depose chez son hebergeur, qui heberge du chiffre
|
|
et ne peut rien juger. Chaque noeud verifie le sien : le service vit SUR LUI, et
|
|
repeter son nom donnerait « idm-01 / sauvegarde: idm-01 ».
|
|
|
|
Le filtre n'acceptait que la premiere forme. Les noeuds recevaient
|
|
`{"error":404,"status":"No objects found."}` — le message d'un objet ABSENT,
|
|
alors qu'il existait et que c'etait la PERMISSION qui refusait. Une heure a
|
|
chercher un objet qui etait la.
|
|
|
|
La portee reste etroite : ce compte ne peut poser un resultat que sur un service
|
|
de sauvegarde, jamais ailleurs.
|
|
#}
|
|
{#
|
|
LES NOMS SONT DERIVES, PAS RECOPIES. Une sonde declaree par un role entre dans ce
|
|
filtre toute seule ; une sonde retiree en sort. Recopier la liste ici, c'etait la
|
|
garantie qu'un jour elle divergerait — et le symptome serait un 404 « No objects
|
|
found » sur un objet qui existe, comme le 2026-09-02. Une heure perdue.
|
|
La portee reste etroite : des NOMS, jamais un joker.
|
|
#}
|
|
filter = {{ '{{' }} match("sauvegarde: *", service.name) || service.name == "sauvegarde" || service.name == "sante"{% for role, sondes in (serveur_icinga_sondes | default({})) | dictsort %}{% for s in sondes %} || service.name == "{{ s.nom }}"{% endfor %}{% endfor %} {{ '}}' }}
|
|
}
|
|
]
|
|
}
|