/* * 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: » — 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. #} filter = {{ '{{' }} match("sauvegarde: *", service.name) || service.name == "sauvegarde" || service.name == "sante" {{ '}}' }} } ] }