Autorisation & RBAC

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer. Le pendant naturel de Identité & SSO : celle-là dit qui tu es, celle-ci dit ce que tu as le droit de faire.

① Le concept (générique)

Authentification (authN) : qui es-tu ? — Autorisation (authZ) : as-tu le droit ? Deux questions distinctes. Se connecter ne dit rien sur ce qu'on peut faire.

RBAC (Role-Based Access Control) : on n'attribue pas des droits à chaque personne, mais des rôles (Viewer, Editor, Admin…), et chaque rôle porte un ensemble de permissions. La personne reçoit un rôle → hérite des droits. Simple, auditable, évolutif.

Où décider ? Deux écoles :

local à l'app : chaque service gère ses propres comptes/rôles (silos, à maintenir partout) ;
centralisé (piloté par le SSO/annuaire) : le rôle voyage dans le jeton ; l'app le lit et l'applique. Une seule source, cohérente partout. Moindre privilège par défaut.

Mécanique OIDC : le fournisseur d'identité met un claim (ex. roles) dans le jeton ; l'app mappe ce claim vers son niveau de droit interne.

② Comment Set-OPS le fait — l'exemple Grafana

Par défaut, un utilisateur SSO arrive en Viewer dans Grafana → il voit les tableaux de bord, mais pas Explore (requêtes ad-hoc). Pour donner Explore aux opérateurs, sans l'ouvrir à tous :

Keycloak : rôle de realm 'grafana-editor'  ──(assigné à testmail)
        + mapper de rôles                  ──> claim "roles":["grafana-editor"] dans le jeton
Grafana  : role_attribute_path             ──> "grafana-editor" ⇒ Editor (⇒ Explore)
                                               "grafana-admin"  ⇒ Admin ; sinon Viewer

Déclaratif dans Set-OPS : serveur_keycloak_realm_roles, _role_mapper_clients, _role_assignments (côté IdP) + serveur_grafana_oidc_role_path (côté app). kcadm à chaud : zéro coupure SSO. Une identité (testmail), et c'est le rôle — pas la connexion — qui décide d'Explore.

Raffinement souverain : ici le rôle est assigné explicitement à testmail. L'idéal est de le piloter par un groupe d'annuaire (LDAP → Keycloak → claim), pour que l'appartenance gouverne l'autorisation. C'est le vrai « l'annuaire gouverne l'accès ».

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
rôles de realm Keycloak → claim	claims/scopes OIDC de tout IdP (Okta, Entra…)
`role_attribute_path` Grafana	role mapping de n'importe quelle app OIDC
RBAC (rôles → permissions)	Kubernetes RBAC · IAM cloud (AWS/GCP) · SGBD (rôles SQL)
moindre privilège	principe universel de sécurité

Tu as appris authZ vs authN, le RBAC, l'autorisation par claim, le moindre privilège — pas « Grafana ».

④ À toi de jouer

Sens le défaut. Avant tout rôle, un nouvel utilisateur SSO est Viewer dans Grafana : il voit le dashboard Journaux de la flotte, mais pas l'icône Explore.
Donne Editor. testmail a le rôle grafana-editor → déconnecte/reconnecte-le (Grafana applique le rôle à la connexion) → Explore apparaît.
Observe le claim. Dans Keycloak (console admin) → Clients → grafana → Client scopes → Evaluate pour testmail : le jeton contient "roles": ["grafana-editor"]. C'est ② en vrai.
Casse & répare. Retire grafana-editor de testmail (ou renomme-le en grafana-viewer), reconnecte : Explore disparaît. Remets-le : il revient. Tu sens que c'est le rôle, pas l'identité, qui ouvre la porte.

Pour aller plus loin (dépôt)

IdP : roles/serveur_keycloak/tasks/rbac-oidc.yml (rôles + mapper + assignations).
App : roles/serveur_grafana (serveur_grafana_oidc_role_path).
Le pendant authentification : unité Identité & SSO.

Set-OPS

🏠 Accueil

Unités d'apprentissage

Fondations

Communication

Données

Observabilité

Socle & méthode

Flotte & preuve

Opérations

Runbooks → dépôt docs/runbooks-exploitation.md

Repères

Glossaire
Référence technique → dépôt docs/