From 086b404b04d1cbbd4308f319066af9a65789dceb Mon Sep 17 00:00:00 2001 From: William Phetsinorath Date: Wed, 14 Oct 2026 12:33:38 +0200 Subject: [PATCH] =?UTF-8?q?doc:=20retirer=20les=20s=C3=A9parateurs=20des?= =?UTF-8?q?=20fiches=20RBAC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Les --- décoratifs entre sections sont propres aux fiches RBAC et redondants avec les titres ; la doc générale ne les utilise pas. Co-authored-by: Automata Signed-off-by: William Phetsinorath Change-Id: I27151096e9b11ae76b8bceaa4e31e23a6a6a6964 --- docs/guide/rbac/console-cpin.md | 14 -------------- docs/guide/rbac/grafana.md | 12 ------------ docs/guide/rbac/harbor.md | 12 ------------ docs/guide/rbac/keycloak.md | 12 ------------ docs/guide/rbac/nexus.md | 12 ------------ docs/guide/rbac/sonarqube.md | 12 ------------ docs/guide/rbac/vault.md | 12 ------------ 7 files changed, 86 deletions(-) diff --git a/docs/guide/rbac/console-cpin.md b/docs/guide/rbac/console-cpin.md index 50cae26..0d4f5e1 100644 --- a/docs/guide/rbac/console-cpin.md +++ b/docs/guide/rbac/console-cpin.md @@ -2,8 +2,6 @@ Ce document décrit le **modèle d'accès** de la Console CPiN elle-même : comment ses rôles admin et projet se traduisent en permissions, et comment ils sont propagés vers Keycloak. ---- - ## Vue par rôle Ce que chaque rôle peut réellement faire dans la Console CPiN. Les chemins `/console/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/` : @@ -20,15 +18,11 @@ Ce que chaque rôle peut réellement faire dans la Console CPiN. Les chemins `/c | Security (administration) | `/console/security` | Lecture transverse (tous projets, audit) | | Guest (utilisateur externe sans groupe) | — | Aucun accès jusqu'à ajout à un projet | ---- - ## 1. Authentification : OIDC via Keycloak - La Console authentifie ses utilisateurs via **OIDC Keycloak**. - Les permissions effectives d'un utilisateur = agrégation (OU binaire) des `permissions` de tous ses rôles (admin + projet). ---- - ## 2. Rôles projet et permissions Chaque projet reçoit 4 rôles système par défaut, liés aux groupes `//console/*`. @@ -44,8 +38,6 @@ Chaque projet reçoit 4 rôles système par défaut, liés aux groupes `// `GUEST(0)`, `MANAGE(1)`, `MANAGE_MEMBERS(2)`, `MANAGE_ENVIRONMENTS(3)`, `MANAGE_REPOSITORIES(4)`, `MANAGE_ROLES(5)`, `SEE_SECRETS(6)`, `REPLAY_HOOKS(7)`, `LIST_ENVIRONMENTS(8)`, `LIST_REPOSITORIES(9)`, `LIST_MEMBERS(10)`, `LIST_ROLES(11)`, `MANAGE_DEPLOYMENTS(12)`, `LIST_DEPLOYMENTS(13)`. ---- - ## 3. Rôles admin et permissions | Rôle Console | Groupe Keycloak (chemin) | Permissions (`ADMIN_PERMS`) | @@ -62,8 +54,6 @@ Chaque projet reçoit 4 rôles système par défaut, liés aux groupes `// > > **Seul un rôle admin peut être lié à un groupe Keycloak existant** via un groupe d'application externe (chemin commençant par `/`). Les rôles projet ont leur groupe d'application préfixé automatiquement par `/`. ---- - ## 4. Points d'attention - **Permissions = masque de bits.** Un rôle est la somme de permissions ; l'agrégation inter-rôles se fait en OU binaire. @@ -72,8 +62,6 @@ Chaque projet reçoit 4 rôles système par défaut, liés aux groupes `// - **DevOps sans déploiement applicatif.** Le déploiement applicatif n'est pas couvert par le rôle DevOps par défaut ; ses droits portent sur les environnements, dépôts, hooks et secrets. - **Groupe `everyonePerms`.** Un projet peut définir des permissions pour _Tout le monde_, appliquées au-delà des rôles nominatifs. ---- - ## 5. Qui gère quoi ? | Élément | Géré par | @@ -82,5 +70,3 @@ Chaque projet reçoit 4 rôles système par défaut, liés aux groupes `// | Rôles admin / projet, permissions | **Console** (base de données) | | Groupes Keycloak dérivés | **Console** (automatique) | | Application des droits | **Console** + outils consommateurs | - ---- diff --git a/docs/guide/rbac/grafana.md b/docs/guide/rbac/grafana.md index 6097d13..bf69481 100644 --- a/docs/guide/rbac/grafana.md +++ b/docs/guide/rbac/grafana.md @@ -2,8 +2,6 @@ Ce document décrit le **modèle d'accès** mis en place dans Grafana pour chaque projet DSO. Contrairement aux autres outils, l'accès Grafana est **scopé par environnement** (prod / hors-prod) et non par rôle projet. ---- - ## Vue par rôle Ce que chaque rôle Console obtient réellement dans Grafana (scopé par environnement). Les chemins `/console/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/` : @@ -21,15 +19,11 @@ Ce que chaque rôle Console obtient réellement dans Grafana (scopé par environ > L'accès réel dépend de la capacité Console par bucket d'environnement : `MANAGE_ENVIRONMENTS` → Editor, `LIST_ENVIRONMENTS` → Viewer, séparément pour hors-prod (`hprod`) et prod. ---- - ## 1. Authentification : Grafana via OIDC Keycloak - Grafana est fédéré au fournisseur OIDC Keycloak. Le mapping **groupe Keycloak → rôle Grafana** est configuré côté Grafana (son fichier de configuration OIDC), pas par la Console. - La Console crée et maintient, **sous le groupe racine `/`**, le sous-groupe `grafana` et ses sous-groupes `hprod-RO/RW` et `prod-RO/RW`. ---- - ## 2. Groupes Keycloak et rôle Grafana résultant | Groupe Keycloak | Rôle Grafana (mapping OIDC) | Portée | @@ -45,16 +39,12 @@ Ce que chaque rôle Console obtient réellement dans Grafana (scopé par environ | `//grafana/prod-RW` | **Editor** (prod) | Projet ``, prod | | `//grafana/prod-RO` | **Viewer** (prod) | Projet ``, prod | ---- - ## 3. Points d'attention - **Scoping prod / hors-prod.** Un utilisateur avec droits sur un environnement `prod` est ajouté aux sous-groupes `prod-*` ; sinon aux `hprod-*` (hors-prod). Les deux peuvent coexister. - **RW vs RO.** `RW` ⇔ capacité `MANAGE_ENVIRONMENTS` (édition) ; `RO` ⇔ `LIST_ENVIRONMENTS` (visualisation). Le propriétaire du projet est toujours RW. - **Le rôle Grafana réel est défini par la config OIDC de Grafana**, pas par la Console. La Console se contente de maintenir l'arborescence de groupes Keycloak. ---- - ## 4. Qui gère quoi ? | Élément | Géré par | @@ -62,5 +52,3 @@ Ce que chaque rôle Console obtient réellement dans Grafana (scopé par environ | Identité OIDC / groupes Keycloak | **Keycloak** | | Arborescence des groupes `grafana/*` | **Console** (automatique) | | Mapping groupe → rôle Grafana | **Grafana** (config OIDC) | - ---- diff --git a/docs/guide/rbac/harbor.md b/docs/guide/rbac/harbor.md index ca46028..fc1f527 100644 --- a/docs/guide/rbac/harbor.md +++ b/docs/guide/rbac/harbor.md @@ -2,8 +2,6 @@ Ce document décrit comment la Console propage les **groupes Keycloak** en **rôles Harbor** (membres d'un projet Harbor), et quels droits en résultent. ---- - ## Vue par rôle Ce que chaque rôle Console obtient réellement dans Harbor. Les chemins `/console/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/` : @@ -20,15 +18,11 @@ Ce que chaque rôle Console obtient réellement dans Harbor. Les chemins `/conso | Security | `/console/security` | **Guest** sur **tous** les projets (lecture transverse) | | Guest | — | Aucun accès | ---- - ## 1. Authentification : Harbor via OIDC Keycloak - Harbor est fédéré au fournisseur OIDC Keycloak ; les utilisateurs se connectent sans mot de passe local. - La Console approvisionne, pour chaque projet, le **projet Harbor** et y ajoute les groupes Keycloak comme **membres** avec un rôle (Admin / Developer / Guest). ---- - ## 2. Groupes Keycloak et rôle Harbor résultant La Console mappe chaque groupe OIDC vers un **rôle Harbor** et une **portée** (projet ou global). @@ -46,15 +40,11 @@ La Console mappe chaque groupe OIDC vers un **rôle Harbor** et une **portée** > Le groupe racine du projet (`/`) est ajouté en tant que membre avec un niveau **Limited Guest** (lecture seule : pull d'images sans administration) pour l'ensemble de ses membres. ---- - ## 3. Points d'attention - **Seul `//console/admin` pousse des images.** Tous les autres rôles projet (`devops`, `developer`, `security`, `reader`) sont en **Guest** (pull/lecture uniquement). - **Groupes `security`/`reader` = Guest transverse.** Ils sont ajoutés en Guest sur **tous** les projets Harbor (portée plateforme), ce qui donne une lecture globale des registres. ---- - ## 4. Qui gère quoi ? | Élément | Géré par | @@ -62,5 +52,3 @@ La Console mappe chaque groupe OIDC vers un **rôle Harbor** et une **portée** | Identité OIDC / groupes Keycloak | **Keycloak** | | Projets Harbor, membres & rôles | **Console** (automatique) | | Application des droits | **Harbor** | - ---- diff --git a/docs/guide/rbac/keycloak.md b/docs/guide/rbac/keycloak.md index 1d7e872..e238429 100644 --- a/docs/guide/rbac/keycloak.md +++ b/docs/guide/rbac/keycloak.md @@ -2,8 +2,6 @@ Ce document décrit le **modèle d'accès** de l'IdP central du socle : Keycloak. Keycloak est la **source de vérité** de l'identité et de la hiérarchie de groupes qui est propagée vers tous les autres outils de la chaîne DSO. ---- - ## Vue par rôle En tant qu'IdP, Keycloak ne « donne » pas d'écran de droits : il place chaque rôle dans un groupe, et c'est ce groupe qui propage les droits en aval. Les chemins `/console/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/`. Conséquence par rôle : @@ -21,15 +19,11 @@ En tant qu'IdP, Keycloak ne « donne » pas d'écran de droits : il place chaque | Security | `/console/security` | Audit/lecture transverse plateforme | | Guest | — | Aucun droit jusqu'à ajout manuel à un projet | ---- - ## 1. Authentification OIDC - Keycloak est le fournisseur d'identité (IdP) ; tous les outils DSO fédèrent dessus en OIDC. - Les utilisateurs proviennent d'un IdP externe (ex. Passage2 / ProConnect) ou sont locaux. Les **rôles admin Console** sont liés à des groupes Keycloak existants via `oidcGroup`. ---- - ## 2. Hiérarchie de groupes maintenue par la Console La Console crée et réconcilie automatiquement l'arborescence suivante, propagée vers les outils consommateurs : @@ -51,8 +45,6 @@ La Console crée et réconcilie automatiquement l'arborescence suivante, propag > ℹ️ Les **rôles projet Console** (`Administrateur`, `DevOps`, `Développeur`, `Lecture seule`) sont systématiquement créés avec le projet et liés aux groupes `//console/{admin,devops,developer,reader}`. Le groupe `//console/security` n'existe pas par défaut : il n'est alimenté que si un outil (ou un admin) le référence. Les rôles admin (`AdminRole`) sont les **seuls** pouvant être liés à un groupe Keycloak **existant** via `oidcGroup` (le préfixe `/` est obligatoire). ---- - ## 3. Points d'attention - **`/admin` est le seul groupe plateforme admin.** Groupe d'amorçage géré en dehors de la Console ; il ne porte des droits que sur la Console CPiN (aucune propagation vers les outils). @@ -60,8 +52,6 @@ La Console crée et réconcilie automatiquement l'arborescence suivante, propag - **Security / Reader sont des portées de lecture/audit**, jamais d'écriture, sur la plupart des outils. - **Utilisateurs tiers (IDP externe).** Aucun groupe par défaut n'est attribué ; ils n'ont aucun droit tant qu'un membre les ajoute à un projet avec le niveau adéquat. ---- - ## 4. Qui gère quoi ? | Élément | Géré par | @@ -69,5 +59,3 @@ La Console crée et réconcilie automatiquement l'arborescence suivante, propag | Fournisseur d'identité / realm | **Keycloak** (socle) | | Hiérarchie de groupes projet/admin | **Console** (automatique) | | Appartenance des utilisateurs aux groupes | **Console** (selon rôles/membres) + **Keycloak** | - ---- diff --git a/docs/guide/rbac/nexus.md b/docs/guide/rbac/nexus.md index 5db4c9f..e1a7f0f 100644 --- a/docs/guide/rbac/nexus.md +++ b/docs/guide/rbac/nexus.md @@ -2,8 +2,6 @@ Ce document décrit le **modèle d'accès** mis en place dans Nexus pour chaque projet DSO : qui peut publier ou télécharger des artefacts, et comment les rôles sont synchronisés depuis les groupes Keycloak. ---- - ## Vue par rôle Ce que chaque rôle Console obtient réellement dans Nexus. Les chemins `/console/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/` : @@ -20,15 +18,11 @@ Ce que chaque rôle Console obtient réellement dans Nexus. Les chemins `/consol | Security | `/console/security` | Lecture de tous les dépôts (plateforme) | | Guest | — | Aucun accès | ---- - ## 1. Authentification : Nexus via OIDC Keycloak - Les utilisateurs se connectent à Nexus via **OIDC** (Keycloak). - La Console approvisionne, pour chaque projet, un **rôle de sécurité** (`-ID` / `-role`) et y rattache les groupes OIDC comme membres avec des _privileges_ de lecture ou d'écriture. ---- - ## 2. Groupes Keycloak et portée Nexus La Console répartit les chemins de groupes OIDC en deux ensembles : **écriture** (publish/deploy) et **lecture** (download/browse). @@ -44,20 +38,14 @@ La Console répartit les chemins de groupes OIDC en deux ensembles : **écriture | `//console/security` | **Lecture** | Dépôt du projet `` | | `//console/readonly` | **Lecture** (packages) | Dépôt du projet `` | ---- - ## 3. Points d'attention - **DevOps = déployer, Developer = télécharger.** Les groupes `admin`/`devops` projet écrivent (publish artefacts, deploy) ; `developer`/`security`/`readonly` ne font que lire/télécharger. - **Rôles agrégés par projet Nexus.** Le rôle `-ID` agrège les privilèges de tous les projets Nexus activés ; un groupe OIDC est rattaché à ce rôle avec le bon niveau (read/write). ---- - ## 4. Qui gère quoi ? | Élément | Géré par | | -------------------------------- | ------------------------- | | Identité OIDC / groupes Keycloak | **Keycloak** | | Rôles & privilèges Nexus | **Console** (automatique) | - ---- diff --git a/docs/guide/rbac/sonarqube.md b/docs/guide/rbac/sonarqube.md index 92e4c61..5625130 100644 --- a/docs/guide/rbac/sonarqube.md +++ b/docs/guide/rbac/sonarqube.md @@ -2,8 +2,6 @@ Ce document décrit le **modèle d'accès** mis en place dans SonarQube pour chaque projet DSO : qui accède à l'analyse, avec quelles permissions, et comment les rôles sont synchronisés depuis les groupes Keycloak. ---- - ## Vue par rôle Ce que chaque rôle Console obtient réellement dans SonarQube. Les chemins `/console/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/` : @@ -20,15 +18,11 @@ Ce que chaque rôle Console obtient réellement dans SonarQube. Les chemins `/co | Security | `/console/security` | identique DevOps (tous projets) | | Guest | — | Aucun accès | ---- - ## 1. Authentification : SonarQube via OIDC Keycloak - Les utilisateurs se connectent à SonarQube via **OIDC** (Keycloak). Aucun compte/mot de passe local à gérer. - La Console approvisionne, pour chaque projet, un **groupe Sonar** et lui applique un **modèle de permissions** (permission template) déduit des groupes OIDC. ---- - ## 2. Groupes Keycloak et permissions SonarQube La Console mappe chaque groupe OIDC vers un ensemble de **permissions projet SonarQube**. @@ -45,14 +39,10 @@ La Console mappe chaque groupe OIDC vers un ensemble de **permissions projet Son > **Égalité devops = developer = security.** Sur un projet, les trois rôles `devops`, `developer` et `security` reçoivent **exactement les mêmes permissions** (`scan`, `user`, `codeviewer`, `issueadmin`, `securityhotspotadmin`). Seul `admin` ajoute `admin`. `reader` se limite à `user` + `codeviewer`. ---- - ## 3. Points d'attention - **Developer et Security ne sont pas en lecture seule.** Contrairement à Vault, ils disposent de `scan` (exécution d'analyse) et de `issueadmin`/`securityhotspotadmin` (traitement des tickets de sécurité). ---- - ## 4. Qui gère quoi ? | Élément | Géré par | @@ -60,5 +50,3 @@ La Console mappe chaque groupe OIDC vers un ensemble de **permissions projet Son | Identité OIDC / groupes Keycloak | **Keycloak** | | Groupes Sonar, permissions, templates | **Console** (automatique) | | Application des droits | **SonarQube** | - ---- diff --git a/docs/guide/rbac/vault.md b/docs/guide/rbac/vault.md index 1bc52ab..186b5d4 100644 --- a/docs/guide/rbac/vault.md +++ b/docs/guide/rbac/vault.md @@ -2,8 +2,6 @@ Ce document décrit le **modèle d'accès** mis en place dans Vault pour chaque projet DSO : qui peut lire/écrire quels secrets, et comment ces droits sont synchronisés depuis les groupes Keycloak. ---- - ## Vue par rôle Ce que chaque rôle Console obtient réellement dans Vault. Les chemins `/console/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/` : @@ -20,16 +18,12 @@ Ce que chaque rôle Console obtient réellement dans Vault. Les chemins `/consol | Security | `/console/security` | Audit & posture plateforme : `sys/audit`, `sys/policies`, `/metadata`, jamais le contenu | | Guest | — | Aucun accès Vault | ---- - ## 1. Authentification : Vault via OIDC Keycloak - Vault expose une méthode d'auth **OIDC** (`oidc/`) dont le fournisseur d'identité est Keycloak. - La Console crée, pour chaque projet, un **mount KV v2** nommé d'après le slug du projet (``), ainsi que les _policies_ et les **groupes d'identité externes** (type `external`) dont l'alias pointe vers le groupe OIDC Keycloak correspondant. - Les applications consomment leurs secrets via un **AppRole** projet (`role-id` / `secret-id`) rattaché aux _policies_ techniques (`tech----ro` + `app----admin`), jamais via OIDC. ---- - ## 2. Groupes Keycloak et _policies_ associées La Console génère, pour chaque projet, les groupes d'identité Vault suivants (nom canonique `project--`), chacun lié à une _policy_ et à un alias OIDC. @@ -47,8 +41,6 @@ La Console génère, pour chaque projet, les groupes d'identité Vault suivants > Un projet possède également un rôle AppRole technique (``) pour les robots CI, rattaché aux _policies_ `tech----ro` (lecture d'un secret de registre dédié) et `app----admin`. ---- - ## 3. Points d'attention - **Développeur = liste seule.** Le rôle `developer` ne dispose que de la capacité `list` sur `/data/*` : il ne peut ni lire ni écrire le contenu d'un secret. @@ -56,8 +48,6 @@ La Console génère, pour chaque projet, les groupes d'identité Vault suivants - **Admin projet ≠ admin plateforme.** `//console/admin` est confiné au mount `/*` ; seul le groupe `/console/admin` obtient `sys/*`. - **Noms canoniques.** le chemin Keycloak réel créé par la Console dépend de la configuration déployée. ---- - ## 4. Qui gère quoi ? | Élément | Géré par | @@ -66,5 +56,3 @@ La Console génère, pour chaque projet, les groupes d'identité Vault suivants | Mounts, _policies_, groupes d'identité, AppRole | **Console** (automatique) | > Pour donner accès à un utilisateur, on l'ajoute au rôle/groupe adéquat côté Console / OIDC ; la Console répercute la _policy_ dans Vault. - ----