diff --git a/docs/.vitepress/sidebar.json b/docs/.vitepress/sidebar.json index 8ae2b01..3ac6823 100644 --- a/docs/.vitepress/sidebar.json +++ b/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" + } + ] } ] }, diff --git a/docs/administration/rbac/console-cpin.md b/docs/administration/rbac/console-cpin.md new file mode 100644 index 0000000..50cae26 --- /dev/null +++ b/docs/administration/rbac/console-cpin.md @@ -0,0 +1,86 @@ +# 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/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/` : + +| Rôle Console | Groupe Keycloak | Ce que je peux faire | +| --------------------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | +| Admin plateforme (administration) | `/console/admin` | Administration globale : tous les projets, utilisateurs, plugins | +| Administrateur projet | `//console/admin` | Gérer le projet : membres, environnements, dépôts, suppression | +| DevOps | `//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 | `//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) | `//console/reader` | Lister environnements et dépôts uniquement | +| Lecture seule (administration) | `/console/reader` | Lecture transverse (tous projets) | +| Security (projet) | `//console/security` | Lecture transverse du projet (audit). _Groupe non créé par défaut : alimenté par les outils qui le référencent_ | +| 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/*`. + +| Rôle Console | Groupe Keycloak | Permissions (bits `PROJECT_PERMS`) | +| ------------------ | --------------------------- | --------------------------------------------------------------------------------------------------------------------- | +| **Administrateur** | `//console/admin` | `MANAGE` (gérer le projet) | +| **DevOps** | `//console/devops` | `SEE_SECRETS`, `REPLAY_HOOKS`, `MANAGE_ENVIRONMENTS`, `MANAGE_REPOSITORIES`, `LIST_ENVIRONMENTS`, `LIST_REPOSITORIES` | +| **Développeur** | `//console/developer` | `MANAGE_REPOSITORIES`, `LIST_ENVIRONMENTS`, `LIST_REPOSITORIES` | +| **Lecture seule** | `//console/reader` | `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) | +| Security (`/console/security`) | `/console/security` | lecture transverse (portée audit, `*RO`) | +| Lecture seule (`/console/reader`) | `/console/reader` | lecture transverse (`*RO`) | + +> **Groupes Keycloak d'administration plateforme** : le chemin plateforme d'administration est `/admin`, groupe d'amorçage géré en dehors de la Console ; `/console/admin` (admin), `/console/security` (audit) et `/console/reader` (lecture) sont les groupes plateforme réconciliés, propagés vers les outils. + +> **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 `//console/` (ex. `/monprojet/console/admin`), sous le groupe racine `/`. Ce chemin est l'identité OIDC effective — il ne porte pas le nom `project--` (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 `/`. + +--- + +## 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. +- **`/admin` donne l'administration globale.** Groupe d'amorçage géré en dehors de la Console. +- **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. 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 | + +--- diff --git a/docs/administration/rbac/grafana.md b/docs/administration/rbac/grafana.md new file mode 100644 index 0000000..6097d13 --- /dev/null +++ b/docs/administration/rbac/grafana.md @@ -0,0 +1,66 @@ +# 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/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/` : + +| Rôle Console | Groupe Keycloak | Accès obtenu dans Grafana | +| --------------------- | ---------------------------------- | -------------------------------- | +| Administrateur projet | `//console/admin` | **Editor** (hors-prod + prod) | +| DevOps | `//console/devops` | **Editor** (hors-prod + prod) | +| Développeur | `//console/developer` | **Viewer** (hors-prod + prod) | +| Lecture seule | `//console/reader` | **Viewer** (projet) | +| Lecture seule | `/console/reader` | **Viewer** (globale) | +| Security | `//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 `/`**, 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 | +| -------------------------------------- | --------------------------- | -------------------------- | +| `/console/security`, `/console/reader` | **Viewer** | Globale (lecture) | +| `//console/admin` | **Editor** | Projet `` | +| `//console/devops` | **Editor** | Projet `` | +| `//console/developer` | **Viewer** | Projet `` | +| `//console/security` | **Viewer** | Projet `` | +| `//console/reader` | **Viewer** | Projet `` | +| `//grafana/hprod-RW` | **Editor** (hors-prod) | Projet ``, hors-prod | +| `//grafana/hprod-RO` | **Viewer** (hors-prod) | Projet ``, hors-prod | +| `//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 | +| ------------------------------------ | ------------------------- | +| Identité OIDC / groupes Keycloak | **Keycloak** | +| Arborescence des groupes `grafana/*` | **Console** (automatique) | +| Mapping groupe → rôle Grafana | **Grafana** (config OIDC) | + +--- diff --git a/docs/administration/rbac/harbor.md b/docs/administration/rbac/harbor.md new file mode 100644 index 0000000..ca46028 --- /dev/null +++ b/docs/administration/rbac/harbor.md @@ -0,0 +1,66 @@ +# 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/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/` : + +| Rôle Console | Groupe Keycloak | Accès obtenu dans Harbor | +| --------------------- | --------------------------- | ------------------------------------------------------- | +| Admin plateforme | `/console/admin` | **Admin** sur tous les projets Harbor | +| Administrateur projet | `//console/admin` | **Developer** sur le projet (push/pull d'images) | +| DevOps | `//console/devops` | **Guest** sur le projet (pull/lecture, pas de push) | +| Développeur | `//console/developer` | **Guest** sur le projet (pull/lecture) | +| Lecture seule | `//console/reader` | **Guest** sur le projet (lecture) | +| Lecture seule | `/console/reader` | **Guest** sur **tous** les projets (lecture transverse) | +| Security | `//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 | Rôle Harbor | Portée | +| ---------------------------------- | ------------------ | ------------------------- | +| `/console/admin` | **Admin** | Tous projets | +| `/console/security` | **Guest** | Tous projets (plateforme) | +| `/console/reader` | **Guest** | Tous projets (plateforme) | +| `//console/admin` | **Developer** | Projet `` | +| `//console/devops` | **Guest** | Projet `` | +| `//console/developer` | **Guest** | Projet `` | +| `//console/security` | **Guest** | Projet `` | +| `//console/reader` | **Guest** | Projet `` | + +> 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 | +| -------------------------------- | ------------------------- | +| Identité OIDC / groupes Keycloak | **Keycloak** | +| Projets Harbor, membres & rôles | **Console** (automatique) | +| Application des droits | **Harbor** | + +--- diff --git a/docs/administration/rbac/keycloak.md b/docs/administration/rbac/keycloak.md new file mode 100644 index 0000000..1d7e872 --- /dev/null +++ b/docs/administration/rbac/keycloak.md @@ -0,0 +1,73 @@ +# Groupes, utilisateurs et droits Keycloak + +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 : + +| Rôle Console | Groupe Keycloak | Propagation en aval | +| --------------------- | --------------------------- | -------------------------------------------- | +| Admin plateforme | `/admin` (amorçage) | Toutes permissions sur la Console uniquement | +| Admin plateforme | `/console/admin` | Admin sur chaque outil (réconcilié, propagé) | +| Administrateur projet | `//console/admin` | Admin du projet partout | +| DevOps | `//console/devops` | RW projet (sauf admin) | +| Développeur | `//console/developer` | Lecture/projet (selon outil) | +| Lecture seule | `//console/reader` | Lecture transverse du projet | +| Lecture seule | `/console/reader` | Lecture transverse plateforme | +| Security | `//console/security` | Audit/lecture transverse du projet | +| 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 : + +| Groupe Keycloak | Nature | Propagé vers | +| ---------------------------------------- | ------------------------------------------------------------------- | ----------------------------------------- | +| `/admin` | Groupe plateforme **admin** (amorçage) | Console uniquement (hors propagation) | +| `/console/admin` | Groupe plateforme **admin** (réconcilié) | Tous les outils (admin sur chaque service)| +| `/console/security` | Groupe plateforme **sécurité** | Tous les outils (audit/security) | +| `/console/reader` | Groupe plateforme **lecture** | Tous les outils (lecture, `*RO`) | +| `//console/admin` | Groupe projet **admin** | Tous les outils (admin projet) | +| `//console/devops` | Groupe projet **devops** | Tous les outils (RW projet) | +| `//console/developer` | Groupe projet **developer** | Tous les outils (selon outil) | +| `//console/security` | Groupe projet **security** | Tous les outils (audit/lecture) | +| `//console/reader` | Groupe projet **reader** | Tous les outils (lecture) | +| `//console//` | Sous-groupes **environnement** (membres en RO, propriétaires en RW) | ArgoCD (`//console//`) | +| `//grafana/-` | Sous-groupes **Grafana** (environnement-scoped) | Grafana | +| Groupes `AdminRole` liés via `oidcGroup` | Rôles admin Console | — | + +> ℹ️ 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). +- **Groupes environnement vs groupes projet.** ArgoCD et Grafana s'appuient sur des sous-groupes **environment-scoped** (`/RO|RW`, `grafana/-RO|RW`). Les autres outils s'appuient sur les groupes **projet-role** (`//console/{admin,devops,developer,reader,security}`). +- **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 | +| ----------------------------------------- | ------------------------------------------------ | +| 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/administration/rbac/nexus.md b/docs/administration/rbac/nexus.md new file mode 100644 index 0000000..5db4c9f --- /dev/null +++ b/docs/administration/rbac/nexus.md @@ -0,0 +1,63 @@ +# Utilisateur et droits Nexus + +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/` : + +| Rôle Console | Groupe Keycloak | Accès obtenu dans Nexus | +| --------------------- | --------------------------- | ----------------------------------------------- | +| Admin plateforme | `/console/admin` | Écriture (admin) sur tous les dépôts | +| Administrateur projet | `//console/admin` | Gérer le dépôt CI/CD du projet (écriture) | +| DevOps | `//console/devops` | Déployer des artefacts (écriture, projet) | +| Développeur | `//console/developer` | Téléchargement de dépendances (lecture, projet) | +| Lecture seule | `//console/readonly` | Lecture des packages/dépôts du projet | +| Lecture seule | `/console/readonly` | Lecture de tous les dépôts (plateforme) | +| Security | `//console/security` | Lecture des dépôts du projet | +| 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). + +| Groupe Keycloak | Type d'accès Nexus | Portée | +| ---------------------------------- | ---------------------------------------- | ------------------------------ | +| `/console/admin` | **Écriture** (admin) | Tous les dépôts | +| `/console/security` | **Lecture** | Tous les dépôts (repos) | +| `/console/readonly` | **Lecture** | Tous les dépôts | +| `//console/admin` | **Écriture** | Dépôt CI/CD du projet `` | +| `//console/devops` | **Écriture** (déployer artefacts) | Dépôt du projet `` | +| `//console/developer` | **Lecture** (téléchargement dépendances) | Dépôt du projet `` | +| `//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/administration/rbac/sonarqube.md b/docs/administration/rbac/sonarqube.md new file mode 100644 index 0000000..92e4c61 --- /dev/null +++ b/docs/administration/rbac/sonarqube.md @@ -0,0 +1,64 @@ +# Utilisateur, groupe et droits SonarQube + +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/` : + +| Rôle Console | Groupe Keycloak | Accès obtenu dans SonarQube | +| --------------------- | ---------------------------------- | ---------------------------------------------------------------------------- | +| Admin plateforme | `/console/admin` | Administer System + profils/gates + création de projets + scan (global) | +| Administrateur projet | `//console/admin` | Admin du projet + scan, codeviewer, issueadmin, securityhotspotadmin | +| DevOps | `//console/devops` | scan + user + codeviewer + issueadmin + securityhotspotadmin | +| Développeur | `//console/developer` | identique DevOps (mêmes permissions projet) | +| Lecture seule | `//console/reader` | user + codeviewer (projet, visualisation) | +| Lecture seule | `/console/reader` | user + codeviewer (tous projets, visualisation) | +| Security | `//console/security` | identique DevOps (mêmes permissions projet) | +| 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**. + +| Groupe Keycloak | Permissions SonarQube (projet) | +| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | +| `/console/admin` | `admin`, `profileadmin`, `gateadmin`, `scan`, `provisioning` (permissions globales) | +| `/console/security`, `/console/reader` | Appliquent les groupes `//console/security` / `//console/reader` sur chaque projet | +| `//console/admin` | `admin`, `scan`, `user`, `codeviewer`, `issueadmin`, `securityhotspotadmin` | +| `//console/devops` | `scan`, `user`, `codeviewer`, `issueadmin`, `securityhotspotadmin` | +| `//console/developer` | `scan`, `user`, `codeviewer`, `issueadmin`, `securityhotspotadmin` | +| `//console/security` | `scan`, `user`, `codeviewer`, `issueadmin`, `securityhotspotadmin` | +| `//console/reader` | `user`, `codeviewer` | + +> **É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 | +| ------------------------------------- | ------------------------- | +| Identité OIDC / groupes Keycloak | **Keycloak** | +| Groupes Sonar, permissions, templates | **Console** (automatique) | +| Application des droits | **SonarQube** | + +--- diff --git a/docs/administration/rbac/vault.md b/docs/administration/rbac/vault.md new file mode 100644 index 0000000..1bc52ab --- /dev/null +++ b/docs/administration/rbac/vault.md @@ -0,0 +1,70 @@ +# Accès et droits Vault + +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/` : + +| Rôle Console | Groupe Keycloak | Accès obtenu dans Vault | +| --------------------- | --------------------------- | ---------------------------------------------------------------------------------------------- | +| Admin plateforme | `/console/admin` | Gestion complète `sys/*` (auth, mounts, policies, entities) | +| Administrateur projet | `//console/admin` | Owner du projet : tout `devops` + gestion des rôles/policies AppRole/transit du projet | +| DevOps | `//console/devops` | Lecture + écriture des secrets du projet (`/data/*`) | +| Développeur | `//console/developer` | Liste des secrets du projet uniquement (pas de lecture/écriture du contenu) | +| Lecture seule | `//console/reader` | Liste des secrets du projet uniquement | +| Lecture seule | `/console/reader` | Lecture plateforme non-sensible : `sys/health`, `sys/mounts`, `sys/auth`, `sys/policies` | +| Security | `//console/security` | Audit projet : `/metadata/*`, `transit/keys//*` | +| 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. + +| Groupe Keycloak | _Policy_ générée | Portée & capacités | +| ---------------------------------------------------------------- | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `/console/admin` (groupe d'identité Vault `console-admin`) | `platform--admin` | **Admin plateforme** : `path "sys/*" { create, read, update, delete, list, sudo }`. | +| `/console/security` (groupe d'identité Vault `console-security`) | `platform--security` | **Audit & posture** : lecture `sys/audit/*`, `sys/policies/*`, `sys/auth/*`. Pas de contenu de secrets. | +| `/console/reader` (groupe d'identité Vault `console-reader`) | `platform--reader` | **Lecture plateforme non-sensible** : `sys/health`, `sys/mounts`, `sys/auth`, `sys/policies`. Pas `/data/*`. | +| `//console/admin` | `app----admin` | **Owner périmètre projet** : tout ce que `devops` + **gestion des rôles d'accès du projet** (policies préfixées projet, AppRole/JWT du projet, clés transit du projet). Pas d'accès hors projet. | +| `//console/devops` | `project----devops` | **RW secrets du projet** (mount ``, chemins relatifs au mount) : `/data/*` {create,read,update,delete,list} ; `/metadata/*` {read,list} ; `/delete\|undelete\|destroy/*` {update}. Pas d'accès aux clés transit ni à AppRole. | +| `//console/developer` | `project----developer` | **List strict projet** : `/data/*` {list}. Rien d'autre. | +| `//console/security` | `project----security` | **Audit projet** : `/metadata/*` {list} ; `transit/keys//*` {list}. Pas `/data/*`. | +| `//console/reader` | `project----reader` | **List strict projet** : `/data/*` {list}. Rien d'autre. | + +> 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. +- **Security = audit, pas données.** Les groupes `security` (plateforme et projet) n'ont accès qu'aux _métadonnées_ et à la posture (`sys/audit`, `/metadata`, `transit/keys`) ; jamais au contenu (`/data`). +- **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 | +| ----------------------------------------------- | ------------------------------------- | +| Identité OIDC / groupes Keycloak | **Keycloak** (fournisseur d'identité) | +| 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. + +---