verifier / verifier (push) Has been cancelled

Details

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

4.7 KiB

Raw Blame History

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.

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

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.

4.7 KiB Raw Blame History