RBAC Arch : audit Azure RBAC à grande échelle avec Codex

Nous avons fait évoluer rbac-arch d’un tableau RBAC local vers un outil d’audit plus exploitable sur de gros tenants Entra ID. Le travail a porté sur deux axes : récupérer les bonnes données Azure sans saturer l’interface, puis rendre la lecture des assignations plus fidèle à la réalité opérationnelle.

Objectif

Le besoin initial était simple : extraire les groupes Entra ID, leurs owners et leurs assignations Azure RBAC dans un format directement consommable par le dashboard. Très vite, deux contraintes sont apparues : certains tenants contiennent plusieurs centaines de milliers de groupes, et une assignation RBAC ne se résume pas à un nom de rôle. Le scope compte autant que le rôle.

Export des groupes possédés par une personne

Un script Python autonome a été ajouté : scripts/export_owned_groups_rbac.py. Il utilise Azure CLI pour résoudre un utilisateur, lister les groupes dont il est owner, parcourir les abonnements visibles par le compte courant, puis récupérer les assignations RBAC associées.

Le JSON produit reste compatible avec l’import existant du dashboard grâce à role_assignments, tout en conservant les détails dans assignment_details : rôle, scope, subscription id et nom de subscription lorsque disponible. Ce choix permet de garder une compatibilité simple tout en préparant une lecture plus précise des accès.

Synchronisation Azure filtrée

La synchronisation Azure a été enrichie avec un filtre de nomenclature côté backend. On peut désormais demander uniquement les groupes contenant, par exemple, PDM ou IA. Le filtre est appliqué dès az ad group list --filter quand Azure CLI le supporte, avant les appels coûteux vers les membres, owners et assignations.

Côté interface, le champ Filtre sync: PDM,IA permet de lancer une sync ciblée. La limite par défaut est passée à 5000 groupes, avec un parallélisme configurable jusqu’à 64 workers.

Opérations en arrière-plan

Les imports et synchronisations longues ne bloquent plus le dashboard. Un registre d’opérations a été ajouté côté API avec GET /operations. Le dashboard affiche maintenant un panneau Operations avec le statut, la phase courante, la progression et les erreurs éventuelles.

Les phases principales sont queued, listing_groups, enriching_groups, refreshing_assignments, completed et failed. Cela donne une visibilité immédiate sur ce qui tourne réellement côté backend.

Performance du dashboard

Un problème important venait des analyses de conformité lancées à chaque rafraîchissement. Sur un tenant volumineux, le dashboard pouvait devenir peu réactif. La page des findings utilise maintenant une limite de détail configurable, fixée à 500 groupes côté interface, tandis que la matrice reste paginée côté serveur.

La recherche dans la matrice a aussi été corrigée. Au lieu de déclencher un appel API à chaque caractère, la saisie est séparée de la recherche envoyée au backend avec un debounce. Résultat : le curseur reste dans le champ et l’interface ne se réinitialise plus à chaque frappe.

Assignations détaillées et refresh par scope

La matrice affichait auparavant seulement les rôles dédupliqués par groupe. Ce modèle masquait le cas fréquent où un même groupe possède plusieurs assignations sur différents scopes. Une colonne Assignments affiche maintenant les détails rôle + scope quand ils sont disponibles.

Nous avons aussi ajouté un endpoint asynchrone dédié : POST /aad/refresh-assignments/async. Il permet de rafraîchir uniquement les assignations RBAC des groupes déjà chargés, sans relister tous les groupes Entra ID. Ce refresh peut être limité à un scope donné et aux groupes ayant déjà des rôles mappés.

Ce que cela change

• La sync peut être ciblée sur une nomenclature métier comme PDM ou IA.
• Les opérations longues sont visibles et suivies en arrière-plan.
• Les gros tenants sont mieux supportés grâce à la pagination, au filtrage et au debounce.
• Les assignations RBAC sont représentées avec leur scope, pas seulement par nom de rôle.
• Il est possible de rafraîchir les scopes sans relancer une synchronisation complète des groupes.

Validation

À chaque étape, les vérifications rapides ont été relancées : compilation Python avec py_compile, build du dashboard React/Vite avec npm run build, commit et push sur la branche de travail codex-export-owned-groups-rbac.