Set-OPS-Public/roles/serveur_icinga/templates/setops-api-users.conf.j2
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

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 %} {{ '}}' }}
}
]
}