🐛 [BUG] - Perte d'accès Grafana : getListPerms ne remplit plus qu'une seule paire de groupes Keycloak (prod XOR hors-prod)

[shikanime]

Problème

Depuis la migration du plugin observability vers apps/server-nestjs (#2418), les utilisateurs perdent l'accès Grafana.

Constat. getListPerms (apps/server-nestjs/src/modules/observability/observability.utils.ts) range chaque utilisateur dans une seule paire de groupes Keycloak : prod si au moins un environnement prod existe, hors-prod sinon. Le plugin historique (cloud-pi-native/console-plugin-observability, src/function.ts) rangeait chaque utilisateur dans les deux paires — le wrapper de hooks Fastify (apps/server/src/utils/hook-wrapper.ts, transformToHookProject) attachait la même liste de permissions à chaque environnement.

Impact. reconcileGroupMembership est une sync diff-and-remove : au premier project.upsert sous server-nestjs, tous les membres du groupe opposé à la paire choisie sont retirés de Keycloak. Grafana associe les rôles org à partir de ces groupes : la perte d'accès est déterministe.

Preuve. Repro : apps/server-nestjs/src/modules/observability/zz-investigate-repro.spec.ts — 2 tests échouent (contrat legacy attendu : utilisateur présent dans les deux paires quand les deux stages existent). Le spec existant (observability.utils.spec.ts) code en dur la sémantique régressive (« assigns to prod bucket when a prod environment exists »).

Définition du fini

• getListPerms restaure le bucketing par stage legacy : un utilisateur apparaît dans la paire prod si un env prod existe et dans la paire hors-prod si un env non-prod existe
• Les assertions du spec unitaire codifiant la sémantique mono-bucket sont corrigées
• Test de non-régression : avec des membres présents dans les deux paires, reconcileGroupMembership ne retire personne (les deux stages présents)
• pnpm lint et tests du workspace server-nestjs verts
• Note de remédiation documentée : rejouer project.upsert par projet affecté pour restaurer les adhésions détruites (idempotent)

Impacts

• Sécurité : retrait destructif d'adhésions Keycloak (perte d'accès Grafana) — sync à corrective après déploiement du fix
• API/données : aucun changement de schéma
• Exploitation : instances affectées nécessitent un replay des hooks projet après mise à jour

[shikanime]

Décision de conception vérifiée contre la doc RBAC

Question soulevée en revue : faut-il abandonner les paires synthétiques /{slug}/grafana/{stage}-{RW,RO} au profit du nouveau layout /{slug}/console/{env}/{RO,RW} ?

Réponse : non. La doc RBAC (documentation/docs/administration/rbac/grafana.md) consacre ce modèle :

• §2 : /<slug>/grafana/hprod-RW|RO, /<slug>/grafana/prod-RW|RO sont les groupes source du mapping OIDC Grafana (Editor/Viewer par stage) ;
• §3 : « Un utilisateur avec droits sur un environnement prod est ajouté aux sous-groupes prod-* ; sinon aux hprod-* (hors-prod). Les deux peuvent coexister. » — c'est exactement la sémantique double-bucket legacy restaurée par ce correctif ;
• §4 : l'arborescence grafana/* est gérée par la Console ; le mapping groupe→rôle est fait par Grafana (config OIDC).

Le chart dso-grafana consomme envs.{stage}.groups[0]/[1] (Editor/Viewer) : les paires synthétiques agrègent N environnements du même stage en deux chemins, ce que le layout par-environnement ne peut pas faire sans changer le chart.

Le layout /{slug}/console/{env}/{RO,RW} est le modèle RBAC projet (admin/devops/developer/security/reader) avec son propre mapping OIDC — un modèle d'accès distinct, pas un remplacement des groupes de staging Grafana.

[shikanime]

Note de remédiation (Définition du fini, item 5)

Le correctif est livré par #2688 (getListPerms bucketing par stage, specs corrigés, garde de non-régression). Après déploiement, les adhésions Keycloak détruites par la régression ne reviennent pas d'elles-mêmes : reconcileGroupMembership est une sync diff-and-remove, elle ne ré-ajoute que ce que getListPerms produit — il faut donc rejouer project.upsert par projet affecté.

Mécanisme de replay (idempotent). Toute mise à jour d'un projet émet project.upsert (apps/server-nestjs/src/modules/project/project.service.ts, action « Update Project »). Le handler observability re-exécute la sync complète (ensureProjectRepository → syncObservabilityConfig → syncKeycloakGroups) et reconcileGroupMembership ré-ajoute les membres manquants des paires prod-RW/RO et hprod-RW/RO sans toucher aux existants. En pratique : re-sauvegarder chaque projet concerné depuis la console (ou PUT sur le projet via l'API).

Périmètre. Uniquement les projets dont une sync project.upsert a tourné sous server-nestjs avec la régression active (ceux ayant à la fois des environnements prod et non-prod ont perdu la paire opposée ; les projets mono-stage sont intacts). Vérification post-replay : keycloak admin — membres des 4 sous-groupes grafana/* par projet, ou logs Observability sync completed for project <slug>.

Fermeture délibérée de cette issue après N-sur-N une fois #2688 fusionné et le replay constaté sur l'instance affectée.

[shikanime]

Preuve de vérification (ledger DoD)

Vérifié contre le diff de #2688 (head b67e78bd, scope : 3 fichiers, +96/−6) et la CI :

1. Bucketing par stage legacy — getListPerms remplit désormais prod ET hors-prod indépendamment, selon les stages présents. Specs « fills the prod bucket when only a prod environment exists », « fills the hors-prod bucket when only non-prod environments exist », « assigns to BOTH buckets when both stages exist (legacy parity) » : verts.
2. Assertions mono-bucket corrigées — les deux titres qui codefiaient la sémantique régressive sont renommés ; constaté dans l'arbre poussé (git show b67e78bd:...observability.utils.spec.ts).
3. Non-régression reconcile — spec syncKeycloakGroups > does not remove existing members from either pair when both stages exist : vert (zéro addUserToGroup/removeUserFromGroup).
4. Lint + tests verts — pnpm lint : vert (workspaces complets). Suite server-nestjs : 617/618. L'unique rouge (plugin.module.spec.ts > resolves PluginService with all plugins enabled) est préexistant à main : reproduit à main tip dans un workspace jj vierge, absent de ce diff. Specs observability : 24/24 verts. CI PR : unit-tests en cours sur b67e78bd.
5. Note de remédiation — publiée : https://github.com/cloud-pi-native/console/issues/2686#issuecomment-5582345213 (replay = re-sauvegarde projet → project.upsert, idempotent ; vérification via les 4 sous-groupes grafana/*).

Le rouge préexistant de plugin.module.spec.ts mérite son propre ticket de triage — hors périmètre de celle-ci.