Set-OPS-Public/wiki/Autorisation-et-RBAC.md

91 lines
4.7 KiB
Markdown
Raw Normal View History

# Autorisation & RBAC
> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.
> Le pendant naturel de **[Identité & SSO](Identité-et-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.
documentation : la tournee des 74 documents, parce qu un balayage ne lit pas La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-06 16:18:23 -04:00
> **Ce « raffinement » est construit depuis le 2026-08-08.** Cette unité le présentait comme
> un idéal à atteindre ; c'est le mécanisme en vigueur. Les **groupes LDAP** sont projetés
> dans Keycloak et émis en claim (`roles/serveur_keycloak/tasks/groupes-ldap.yml` et
> `claim-groupes.yml`), et chaque service déclare le groupe qu'il reconnaît dans son
> `meta/acces.yml` — `sysadmin ⇒ Admin`, `personnel ⇒ Viewer` chez Grafana. C'est donc bien
> **l'appartenance** qui gouverne, pas une assignation nominative.
>
> La règle qui va avec : **un service nomme un groupe, jamais une personne**. Nommer
> quelqu'un créerait une dette qu'on découvre le jour du départ, service par service — et il
> faudrait un déploiement pour révoquer. L'assignation explicite à `testmail` de l'exemple
> ci-dessus reste utile pour *comprendre* la mécanique du claim ; ce n'est pas la façon dont
> on donne un accès. Voir `docs/autorisation.md` §5.
---
## ③ 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
1. **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.
2. **Donne Editor.** `testmail` a le rôle `grafana-editor` → **déconnecte/reconnecte-le** (Grafana
applique le rôle *à la connexion*) → **Explore apparaît**.
3. **Observe le claim.** Dans Keycloak (console admin) → Clients → grafana → *Client scopes* →
*Evaluate* pour `testmail` : le jeton contient `"roles": ["grafana-editor"]`. C'est ② en vrai.
4. **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](Identité-et-SSO)**.