feat(server-nestjs): implémenter le RBAC fins d'observability

[shikanime]

Issues liées

Issues numéro :

• 💡 [REQUEST] - Adapter la console afin d'interpréter les rôles des utilisateurs #1795 — Adapter la console afin d'interpréter les rôles des utilisateurs (RBAC, parent)
• 💡 [REQUEST] - Création des rôles projet #1733 — Création des rôles projet (matrice d'affectation des droits, second temps)
• 💡 [REQUEST] - Attribution des rôles aux utilisateurs depuis la console #1734 — Attribution des rôles aux utilisateurs depuis la console
• 💡 [REQUEST] - Création des rôles transverses #1732 - Creation des rôles observabilité

---

Quel est le comportement actuel ?

Le plugin observability (server-nestjs) synchronise uniquement les sous-groupes Grafana legacy grafana/<env>-<RO|RW> dans Keycloak à partir de getListPerms. Les groupes hiérarchiques /<slug>/console/<role> définis par l'ADR 014 (droits fins) ne sont ni créés ni propagés dans les values Grafana.

Quel est le nouveau comportement ?

• getRbacPerms(project) calcule, depuis la matrice de permissions bitmask (@cpn-console/shared), l'appartenance d'un utilisateur à un rôle fin : MANAGE → admin, MANAGE_ENVIRONMENTS → devops, LIST_ENVIRONMENTS → readonly (le propriétaire est admin).
• generateProjectRbacGroupPath(project, role) produit le chemin de groupe Keycloak hiérarchique /<slug>/console/<role> (ADR 014, cohérent avec les autres modules à droits fins : vault, project, sonarqube).
• Lors des events create/update/delete, le service crée/met à jour/supprime ces groupes dans Keycloak en parallèle des sous-groupes Grafana legacy (étape 1 de migration : coexistence).
• Les nouveaux groupes sont publiés dans les values Grafana générées (generateObservabilityProject).
• Tests unitaires Vitest : getRbacPerms (mapping des permissions, exclusion des membres sans permission) et generateProjectRbacGroupPath.

Cette PR introduit-elle un breaking change ?

Non. Les groupes legacy sont conservés ; les nouveaux groupes s'ajoutent sans rupture (migration progressive, étape 1/3 de l'ADR 014). La suppression des sous-groupes legacy (étape 3) et les guards d'autorisation Keycloak/CASL (ADR 019) restent hors périmètre de cette PR.

Autres informations

• Scope délibérément limité au module observability (pas de guard applicatif global).
• Reste à faire : retrait des sous-groupes legacy une fois les nouveaux groupes provisionnés par les outils cibles.

[shikanime]

Revue — PR #2435 (RBAC fins observability, ADR 014)

Vérifié localement sur a77ab03 :

• ✅ Tests : 26/26 passants (dont 5 nouveaux : getRbacPerms ×4, generateProjectRbacGroupPath, + test de suppression de service)
• ✅ ESLint : propre sur les 5 fichiers modifiés
• ✅ nest build : vert (après bootstrap du workspace)

⚠️ Warning

• observability.service.ts — syncRbacGroups (chemin create/reconcile sur handleUpsert) n'a pas de test de service dédié. Les utils sont couverts et le chemin de suppression l'est, mais la création/réconciliation sur upsert n'est pas assertée. Ajouter un test vérifiant que handleUpsert appelle getOrCreateGroupByPath pour chaque rôle et addUserToGroup pour les membres mappés.

🔎 Nit

• observability.utils.ts — getRbacPerms : le commentaire « Grafana mapping (ADR 014): admin/devops -> Editor, readonly -> Viewer » est placé sur la fonction qui calcule l'appartenance aux groupes Keycloak, pas le mapping de rôle Grafana (downstream). À reformuler en « RBAC role assignment from bitmask perms ».

Points positifs

• Le shape de chemin /<slug>/console/{admin,devops,readonly} correspond exactement aux groupes OIDC canoniques de project.utils.ts:43,55,71 → observability réutilise les mêmes groupes Keycloak (design ADR-014 partagé), pas de fork.
• reconcileMembers déduplique la logique add/remove entre les sous-groupes Grafana legacy et les nouveaux groupes RBAC — bon DRY.
• Précédence mono-rôle (manage > rw > ro) et owner-toujours-admin respectés ; guard défensif if (!group?.id) continue en suppression.

Verdict : APPROVE

Aucun blocker. Ajouter le test du chemin upsert avant merge. Transmis à @cloud-pi-native/socle pour la revue d'habilitation approfondie (guards ADR-019 hors périmètre de cette PR).

[cloud-pi-native-sonarqube]

Quality Gate passed

Issues

• 0 New Issues
• 0 Fixed Issues
• 0 Accepted Issues

Measures

• 0 Security Hotspots
• 0.00% Coverage (42.40% Estimated after merge)
• 0.00% Duplicated Code (4.00% Estimated after merge)

Project ID: cloud-pi-native_console_AYsa46O31ebDtzs-pYyZ

View in SonarQube