docs: publier les fiches RBAC outils sous administration/rbac

docs/.vitepress/sidebar.json

@@ -279,6 +279,40 @@
       {
         "text": "Plugins",
         "link": "/administration/plugins"
+      },
+      {
+        "text": "Droits fins (RBAC outils)",
+        "collapsed": true,
+        "items": [
+          {
+            "text": "Console CPiN",
+            "link": "/administration/rbac/console-cpin"
+          },
+          {
+            "text": "Vault",
+            "link": "/administration/rbac/vault"
+          },
+          {
+            "text": "Keycloak",
+            "link": "/administration/rbac/keycloak"
+          },
+          {
+            "text": "Harbor",
+            "link": "/administration/rbac/harbor"
+          },
+          {
+            "text": "Nexus",
+            "link": "/administration/rbac/nexus"
+          },
+          {
+            "text": "SonarQube",
+            "link": "/administration/rbac/sonarqube"
+          },
+          {
+            "text": "Grafana",
+            "link": "/administration/rbac/grafana"
+          }
+        ]
       }
     ]
   },

docs/administration/rbac/console-cpin.md

@@ -0,0 +1,102 @@
+# Utilisateurs, groupes et droits Console CPiN
+
+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/<rôle>` sont **réservés à l'administration plateforme** et distincts des rôles projet `/<slug>/console/<rôle>` :
+
+| Rôle Console | Groupe Keycloak | Ce que je peux faire |
+| --- | --- | --- |
+| Admin plateforme (administration) | `/console/admin` | Administration globale : tous les projets, utilisateurs, plugins |
+| Administrateur projet | `/<slug>/console/admin` | Gérer le projet : membres, environnements, dépôts, suppression |
+| DevOps | `/<slug>/console/devops` | Gérer environnements + dépôts, rejouer les hooks, voir les secrets. **Pas** de déploiement applicatif ni de gestion des membres |
+| Développeur | `/<slug>/console/developer` | Gérer et lister les dépôts, lister les environnements. **Pas** d'accès aux secrets ni de rejeu du projet |
+| Lecture seule (projet) | `/<slug>/console/readonly` | Lister environnements et dépôts uniquement |
+| Lecture seule (administration) | `/console/readonly` | Lecture transverse (tous projets) |
+| Security (projet) | `/<slug>/console/security` | Lecture transverse du projet (audit) |
+| 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 `/<slug>/console/*`.
+
+| Rôle Console | Groupe Keycloak (ADR 014) | Permissions (bits `PROJECT_PERMS`) |
+| --- | --- | --- |
+| **Administrateur** | `/<slug>/console/admin` | `MANAGE` (gérer le projet) |
+| **DevOps** | `/<slug>/console/devops` | `SEE_SECRETS`, `REPLAY_HOOKS`, `MANAGE_ENVIRONMENTS`, `MANAGE_REPOSITORIES`, `LIST_ENVIRONMENTS`, `LIST_REPOSITORIES` |
+| **Développeur** | `/<slug>/console/developer` | `SEE_SECRETS`, `REPLAY_HOOKS`, `MANAGE_REPOSITORIES`, `LIST_ENVIRONMENTS`, `LIST_REPOSITORIES` |
+| **Lecture seule** | `/<slug>/console/readonly` | `LIST_ENVIRONMENTS`, `LIST_REPOSITORIES` |
+
+### Bits `PROJECT_PERMS` disponibles
+`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`) |
+| --- | --- | --- |
+| Admin plateforme (`/console/admin`) | `/console/admin` | `MANAGE` + toutes les `MANAGE_*`, `LIST_*` (admin global) |
+| Admin plateforme (nom de groupe `console-admin`) | `console-admin` | identique à `/console/admin` (même périmètre admin global) — nom utilisé côté Vault |
+| Security (`/console/security`) | `/console/security` | lecture transverse (portée audit, `*RO`) |
+| Lecture seule (`/console/readonly`) | `/console/readonly` | lecture transverse (`*RO`) |
+
+> **Groupes Keycloak d'administration plateforme** : les seuls chemins Keycloak réels sont `/console/admin`, `/console/security` et `/console/readonly` (nommage en sous-groupes conservé et étendu par rétro-compatibilité). Les noms `console-admin`, `console-security`, `console-readonly` désignent le *nom* de groupe (sans `/`) dans certains outils (ex. Vault), mais le chemin Keycloak effectif reste `/console/<rôle>`.
+>
+> **`platform-admin` / `platform-security` / `platform-readonly` ne sont PAS des groupes Keycloak.** Ce sont les *policies* internes Vault (`platform--admin` / `platform--security` / `platform--readonly`) couplées aux rôles `console-*`, représentant la portée transversale (tous projets).
+
+> **Axe ABAC `userType`** : indépendamment des groupes, certains endpoints restreignent l'accès selon le type d'utilisateur (`human` / `bot` / `ghost`, colonne `User.type`). Cet axe s'ajoute au masque de bits admin/projet.
+
+> **Chemin Keycloak réel des rôles projet** : la Console crée `/<slug>/console/<rôle>` (ex. `/monprojet/console/admin`), sous le groupe racine `/<slug>`. Ce chemin est l'identité OIDC effective — il ne porte pas le nom `project-<name>-<rôle>` (qui n'existe pas côté Keycloak).
+>
+> **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 `/<slug>`.
+
+---
+
+## 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.
+- **`/console/admin` (nom `console-admin`) donne l'administration globale.** C'est le seul groupe Keycloak d'admin plateforme ; `platform-admin` est une policy Vault interne de même périmètre.
+- **Le développeur n'accède pas aux secrets.** Le rôle `developer` couvre la gestion des dépôts et la lecture des environnements ; ni `SEE_SECRETS` ni `REPLAY_HOOKS` ne lui sont accordés (contrairement à DevOps).
+- **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. Mise en cohérence automatique
+
+- À la création d'un projet, la Console initialise les rôles projet système liés aux groupes `/<slug>/console/*`.
+- À chaque mise à jour, la Console crée les groupes Keycloak correspondants et synchronise les membres selon leurs rôles.
+- Les rôles admin liés à un groupe d'application externe sont réconciliés vers des groupes Keycloak existants (créés si absents).
+
+---
+
+## 6. Qui gère quoi ?
+
+| Élément | Géré par |
+| --- | --- |
+| Identité OIDC | **Keycloak** |
+| Rôles admin / projet, permissions | **Console** (base de données) |
+| Groupes Keycloak dérivés | **Console** (automatique) |
+| Application des droits | **Console** + outils consommateurs |
+
+---
+
+## 7. Références
+
+- Fiche « Hooks transverses - membres, roles, zones, clusters » (ce dossier).
+- Fiche « Mécanisme des hooks et plugins ».
+- **Matrice RBAC** : ADR « Gestion des droits fins » (table Console, section *Decision*).

docs/administration/rbac/grafana.md

@@ -0,0 +1,83 @@
+# Utilisateurs, groupes et droits Grafana
+
+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/<rôle>` sont **réservés à l'administration plateforme** et distincts des rôles projet `/<slug>/console/<rôle>` :
+
+| Rôle Console | Groupe Keycloak (ADR 014) | Accès obtenu dans Grafana |
+| --- | --- | --- |
+| Admin plateforme | `console-admin` (`/console/admin`) | **Organization Admin** (globale) |
+| Administrateur projet | `/<slug>/console/admin` | **Editor** (hors-prod + prod) |
+| DevOps | `/<slug>/console/devops` | **Editor** (hors-prod + prod) |
+| Développeur | `/<slug>/console/developer` | **Viewer** (hors-prod + prod) |
+| Lecture seule | `/<slug>/console/readonly` | **Viewer** (projet) |
+| Lecture seule | `/console/readonly` | **Viewer** (globale) |
+| Security | `/<slug>/console/security` | **Viewer** (projet) |
+| Security | `/console/security` | **Viewer** (globale) |
+| Guest | — | Aucun accès |
+
+> 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 `/<slug>`**, 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 (ADR 014) | Rôle Grafana (mapping OIDC) | Portée |
+| --- | --- | --- |
+| `console-admin` (`/console/admin`) | **Organization Admin** | Globale |
+| `/console/security`, `/console/readonly` | **Viewer** | Globale (lecture) |
+| `/<slug>/console/admin` | **Editor** | Projet `<name>` |
+| `/<slug>/console/devops` | **Editor** | Projet `<name>` |
+| `/<slug>/console/developer` | **Viewer** | Projet `<name>` |
+| `/<slug>/console/security` | **Viewer** | Projet `<name>` |
+| `/<slug>/console/readonly` | **Viewer** | Projet `<name>` |
+| `/<slug>/grafana/hprod-RW` | **Editor** (hors-prod) | Projet `<slug>`, hors-prod |
+| `/<slug>/grafana/hprod-RO` | **Viewer** (hors-prod) | Projet `<slug>`, hors-prod |
+| `/<slug>/grafana/prod-RW` | **Editor** (prod) | Projet `<slug>`, prod |
+| `/<slug>/grafana/prod-RO` | **Viewer** (prod) | Projet `<slug>`, 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.
+- **Un seul groupe admin plateforme.** `console-admin` (`/console/admin`) obtient le rôle **Organization Admin** (globale). `platform-admin` n'est pas un groupe Keycloak — c'est une *policy* Vault interne.
+- **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. Mise en cohérence automatique
+
+À chaque réconciliation de projet, la Console synchronise l'arborescence de groupes Grafana du projet.
+
+L'opération est **idempotente**.
+
+---
+
+## 5. Qui gère quoi ?
+
+| Élément | Géré par |
+| --- | --- |
+| Identité OIDC / groupes Keycloak | **Keycloak** |
+| Arborescence des groupes `grafana/*` | **Console** (automatique) |
+| Mapping groupe → rôle Grafana | **Grafana** (config OIDC) |
+
+---
+
+## 6. Références
+
+- Fiche « Provisionnement automatique par la Console » (ce dossier).
+- Fiche « Architecture GitOps de l'observabilité ».
+- **Matrice RBAC** : ADR « Gestion des droits fins ».

docs/administration/rbac/harbor.md

@@ -0,0 +1,81 @@
+# Groupes Keycloak et Harbor
+
+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/<rôle>` sont **réservés à l'administration plateforme** et distincts des rôles projet `/<slug>/console/<rôle>` :
+
+| Rôle Console | Groupe Keycloak (ADR 014) | Accès obtenu dans Harbor |
+| --- | --- | --- |
+| Admin plateforme | `console-admin` | **Admin (global)** : gestion de tous les projets Harbor |
+| Administrateur projet | `/<slug>/console/admin` | **Developer** sur le projet (push/pull d'images) |
+| DevOps | `/<slug>/console/devops` | **Guest** sur le projet (pull/lecture, pas de push) |
+| Développeur | `/<slug>/console/developer` | **Guest** sur le projet (pull/lecture) |
+| Lecture seule | `/<slug>/console/readonly` | **Guest** sur le projet (lecture) |
+| Lecture seule | `/console/readonly` | **Guest** sur **tous** les projets (lecture transverse) |
+| Security | `/<slug>/console/security` | **Guest** sur le projet (lecture) |
+| 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).
+
+| Groupe Keycloak (ADR 014) | Rôle Harbor | Portée |
+| --- | --- | --- |
+| `console-admin` (`/console/admin`) | **Admin** (global) | Global |
+| `/console/security` | **Guest** | Tous projets (plateforme) |
+| `/console/readonly` | **Guest** | Tous projets (plateforme) |
+| `/<slug>/console/admin` | **Developer** | Projet `<name>` |
+| `/<slug>/console/devops` | **Guest** | Projet `<name>` |
+| `/<slug>/console/developer` | **Guest** | Projet `<name>` |
+| `/<slug>/console/security` | **Guest** | Projet `<name>` |
+| `/<slug>/console/readonly` | **Guest** | Projet `<name>` |
+
+> Le groupe racine du projet (`/<slug>`) est ajouté en tant que membre avec un niveau **Limited Guest** (pas de tirage d'images) pour l'ensemble de ses membres.
+
+---
+
+## 3. Points d'attention
+
+- **Admin plateforme = Admin global Harbor.** `console-admin` (`/console/admin`) obtient le rôle **Admin** Harbor (gestion de tous les projets), pas un simple rôle de projet.
+- **Seul `/<slug>/console/admin` pousse des images.** Tous les autres rôles projet (`devops`, `developer`, `security`, `readonly`) sont en **Guest** (pull/lecture uniquement).
+- **Groupes `security`/`readonly` = 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. Mise en cohérence automatique
+
+À chaque réconciliation de projet, la Console synchronise les membres et rôles du projet Harbor.
+
+L'opération est **idempotente**.
+
+---
+
+## 5. Qui gère quoi ?
+
+| Élément | Géré par |
+| --- | --- |
+| Identité OIDC / groupes Keycloak | **Keycloak** |
+| Projets Harbor, membres & rôles | **Console** (automatique) |
+| Application des droits | **Harbor** |
+
+---
+
+## 6. Références
+
+- Fiche « Provisionnement automatique par la Console » (ce dossier).
+- Fiche « Secrets Vault et Harbor ».
+- **Matrice RBAC** : ADR « Gestion des droits fins ».