Daniel Allaire
6f2acafdb6
Chaque role web declare le GROUPE qu'il reconnait et ce qu'il lui accorde. Un troisieme champ s'est impose en ecrivant : `porte_par` — le mecanisme qui transporte reellement l'habilitation. Sans lui, les declarations auraient decrit une chaine inexistante. Etat mesure : grafana `role-realm` (reel) ; forgejo, nextcloud et keycloak `aucun` ; icingaweb2 `liste-uid` — il NOMME DES PERSONNES, ce que D-66 interdit. Le maillon manquant est chez Keycloak : `role_assignments` assigne un role a un UTILISATEUR, et son propre commentaire l'admettait (« en prod, preferer l'assignation via groupe d'annuaire »). Sans group-ldap-mapper, les groupes LDAP n'atteignent jamais les services. Sa meta a donc une autre forme, `acces_projection` : Keycloak projette au lieu de consommer (D-65). Defaut corrige : `serveur_icingaweb2_admins` valait "testmail", un compte de test code en dur dans le moteur qu'aucune instance ne surchargeait — le seul administrateur declare de la supervision etait un utilisateur inexistant. Il suit desormais l'uid d'amorcage. Verifie sur mon-01 : users = "sysadmin". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
13 lines
612 B
YAML
13 lines
612 B
YAML
---
|
|
# Habilitations reconnues par ce service. Voir docs/autorisation.md.
|
|
acces:
|
|
- groupe: sysadmin
|
|
accorde: Administrateur
|
|
# /!\ `liste-uid` NOMME DES PERSONNES (`serveur_icingaweb2_admins`), ce que
|
|
# D-66 interdit : revoquer quelqu'un demande alors un deploiement, et le
|
|
# service porte une liste qui vieillit sans que rien ne le signale.
|
|
# Icinga Web 2 sait lire un groupe d'annuaire (backend LDAP de type `group`) :
|
|
# c'est vers cela qu'il faut aller. Constate le 2026-08-07.
|
|
porte_par: liste-uid
|
|
raison: >-
|
|
Acces complet a la supervision : hotes, services, commandes.
|