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..d6240de --- /dev/null +++ b/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/` 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/readonly` | Lister environnements et dépôts uniquement | +| Lecture seule (administration) | `/console/readonly` | Lecture transverse (tous projets) | +| Security (projet) | `//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 `//console/*`. + +| Rôle Console | Groupe Keycloak (ADR 014) | 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` | `SEE_SECRETS`, `REPLAY_HOOKS`, `MANAGE_REPOSITORIES`, `LIST_ENVIRONMENTS`, `LIST_REPOSITORIES` | +| **Lecture seule** | `//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/`. +> +> **`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 `//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. +- **`/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 `//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*). diff --git a/docs/administration/rbac/grafana.md b/docs/administration/rbac/grafana.md new file mode 100644 index 0000000..f8ff407 --- /dev/null +++ b/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/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/` : + +| Rôle Console | Groupe Keycloak (ADR 014) | Accès obtenu dans Grafana | +| --- | --- | --- | +| Admin plateforme | `console-admin` (`/console/admin`) | **Organization Admin** (globale) | +| 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/readonly` | **Viewer** (projet) | +| Lecture seule | `/console/readonly` | **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 (ADR 014) | Rôle Grafana (mapping OIDC) | Portée | +| --- | --- | --- | +| `console-admin` (`/console/admin`) | **Organization Admin** | Globale | +| `/console/security`, `/console/readonly` | **Viewer** | Globale (lecture) | +| `//console/admin` | **Editor** | Projet `` | +| `//console/devops` | **Editor** | Projet `` | +| `//console/developer` | **Viewer** | Projet `` | +| `//console/security` | **Viewer** | Projet `` | +| `//console/readonly` | **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. +- **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 ». diff --git a/docs/administration/rbac/harbor.md b/docs/administration/rbac/harbor.md new file mode 100644 index 0000000..771cde9 --- /dev/null +++ b/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/` sont **réservés à l'administration plateforme** et distincts des rôles projet `//console/` : + +| 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 | `//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/readonly` | **Guest** sur le projet (lecture) | +| Lecture seule | `/console/readonly` | **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 (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) | +| `//console/admin` | **Developer** | Projet `` | +| `//console/devops` | **Guest** | Projet `` | +| `//console/developer` | **Guest** | Projet `` | +| `//console/security` | **Guest** | Projet `` | +| `//console/readonly` | **Guest** | Projet `` | + +> Le groupe racine du projet (`/`) 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 `//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 ». diff --git a/docs/administration/rbac/keycloak.md b/docs/administration/rbac/keycloak.md new file mode 100644 index 0000000..5d71396 --- /dev/null +++ b/docs/administration/rbac/keycloak.md @@ -0,0 +1,85 @@ +# 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 (ADR 014) | Propagation en aval | +| --- | --- | --- | +| Admin plateforme | `console-admin` | Admin partout | +| 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/readonly` | Lecture transverse du projet | +| Lecture seule | `/console/readonly` | 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 (noms canoniques ADR 014), propagée vers les outils consommateurs : + +| Groupe Keycloak (ADR 014) | Nature | Propagé vers | +| --- | --- | --- | +| `console-admin` | Groupe plateforme **admin** | Tous les outils (Admin global) | +| `/console/security` | Groupe plateforme **sécurité** | Tous les outils (audit/security) | +| `/console/readonly` | 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/readonly` | Groupe projet **readonly** | 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`, `Security`) sont systématiquement liés aux groupes `//console/{admin,devops,developer,readonly,security}`. 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 + +- **`/console/admin` (nom `console-admin`) est le seul groupe plateforme admin.** `platform-admin`, `platform-security`, `platform-readonly` ne sont pas des groupes Keycloak : ce sont des *policies* internes Vault attachées aux groupes `/console/*`. +- **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,readonly,security}`). +- **Security / Readonly 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. Mise en cohérence automatique + +La Console réconcilie à chaque création/mise à jour de projet ou d'admin-role l'arborescence et l'appartenance des groupes Keycloak. + +L'opération est **idempotente**. + +--- + +## 5. 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** | + +--- + +## 6. Références + +- Fiche « Provisionnement automatique par la Console » (ce dossier). +- Fiche « Activation OTP obligatoire pour admins ». +- **Matrice RBAC** (groupes Keycloak ↔ droits par outil) : ADR « Gestion des droits fins ». diff --git a/docs/administration/rbac/nexus.md b/docs/administration/rbac/nexus.md new file mode 100644 index 0000000..9ac47d9 --- /dev/null +++ b/docs/administration/rbac/nexus.md @@ -0,0 +1,78 @@ +# 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 (ADR 014) | Accès obtenu dans Nexus | +| --- | --- | --- | +| Admin plateforme | `console-admin` | **Admin** : gestion de 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 (ADR 014) | Type d'accès Nexus | Portée | +| --- | --- | --- | +| `console-admin` (`/console/admin`) | **Admin** + lecture tous projets | 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. +- **Admin plateforme = Admin Nexus.** `console-admin` (`/console/admin`) obtient les privilèges Admin + lecture de tous les dépôts (rôles platform agrégés sur l'ensemble des projets). +- **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. Mise en cohérence automatique + +À chaque réconciliation de projet, la Console synchronise les rôles et privilèges Nexus du projet. + +L'opération est **idempotente**. + +--- + +## 5. Qui gère quoi ? + +| Élément | Géré par | +| --- | --- | +| Identité OIDC / groupes Keycloak | **Keycloak** | +| Rôles & privilèges Nexus | **Console** (automatique) | + +--- + +## 6. Références + +- Fiche « Provisionnement automatique par la Console » (ce dossier). +- Fiche « Secrets Vault et Nexus ». +- **Matrice RBAC** : ADR « Gestion des droits fins ». diff --git a/docs/administration/rbac/sonarqube.md b/docs/administration/rbac/sonarqube.md new file mode 100644 index 0000000..b332425 --- /dev/null +++ b/docs/administration/rbac/sonarqube.md @@ -0,0 +1,79 @@ +# 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 (ADR 014) | Accès obtenu dans SonarQube | +| --- | --- | --- | +| Admin plateforme | `console-admin` (`/console/admin`) | Administer System + profils/quality gates + **création de projets** (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/readonly` | user + codeviewer (projet, visualisation) | +| Lecture seule | `/console/readonly` | 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 (ADR 014) | Permissions SonarQube (projet) | +| --- | --- | +| `console-admin` (`/console/admin`) | **Administer System**, **Administer Quality Profiles**, **Administer Quality Gates**, **Create Projects** (admin global) | +| `/console/security`, `/console/readonly` | Appliquent les groupes `//console/security` / `//console/readonly` 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/readonly` | `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`. `readonly` 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é). +- **Admin projet ≠ admin global.** `//console/admin` administre **le projet Sonar**, pas l'instance. L'admin global (`Administer System`, profils, gates, création de projets) est réservé à `console-admin` (`/console/admin`). + +--- + +## 4. Mise en cohérence automatique + +À chaque réconciliation de projet, la Console synchronise les groupes et permissions SonarQube du projet. + +L'opération est **idempotente**. + +--- + +## 5. Qui gère quoi ? + +| Élément | Géré par | +| --- | --- | +| Identité OIDC / groupes Keycloak | **Keycloak** | +| Groupes Sonar, permissions, templates | **Console** (automatique) | +| Application des droits | **SonarQube** | + +--- + +## 6. Références + +- Fiche « Provisionnement automatique par la Console » (ce dossier). +- Fiche « Secrets Vault et SonarQube ». +- **Matrice RBAC** : ADR « Gestion des droits fins ». diff --git a/docs/administration/rbac/vault.md b/docs/administration/rbac/vault.md new file mode 100644 index 0000000..674502b --- /dev/null +++ b/docs/administration/rbac/vault.md @@ -0,0 +1,85 @@ +# 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 (ADR 014) | Accès obtenu dans Vault | +| --- | --- | --- | +| Admin plateforme | `console-admin` | Admin global : 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 (`kv/data//*`) | +| Développeur | `//console/developer` | Liste des secrets du projet uniquement (pas de lecture/écriture du contenu) | +| Lecture seule | `//console/readonly` | Liste des secrets du projet uniquement | +| Lecture seule | `/console/readonly` | Lecture plateforme non-sensible : `sys/health`, `sys/mounts`, `sys/auth`, `sys/policies` | +| Security | `//console/security` | Audit projet : `kv/metadata//*`, `transit/keys//*` | +| Security | `/console/security` | Audit & posture plateforme : `sys/audit`, `sys/policies`, `kv/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 (ADR 014) | *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/readonly` (groupe d'identité Vault `console-readonly`) | `platform--readonly` | **Lecture plateforme non-sensible** : `sys/health`, `sys/mounts`, `sys/auth`, `sys/policies`. Pas `kv/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** : `kv/data//*` {create,read,update,delete,list} ; `kv/metadata/*` {read,list} ; `kv/delete\|undelete\|destroy/*` {update} ; usage clés transit ; gestion AppRole CI (lecture `role-id`, génération `secret-id`). | +| `//console/developer` | `project----readonly` | **List strict projet** : `kv/data//*` {list}. Rien d'autre. | +| `//console/security` | `project----security` | **Audit projet** : `kv/metadata//*` {list} ; `transit/keys//*` {list}. Pas `kv/data/*`. | +| `//console/readonly` | `project----readonly` | **List strict projet** : `kv/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 `kv/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`, `kv/metadata`, `transit/keys`) ; jamais au contenu (`kv/data`). +- **Admin projet ≠ admin plateforme.** `//console/admin` est confiné au mount `/*` ; seul le groupe `/console/admin` obtient `sys/*`. +- **Groupe = matrice ADR 014.** Les noms ci-dessus sont canoniques (ADR 014) ; le chemin Keycloak réel créé par la Console dépend de la configuration déployée. + +--- + +## 4. Mise en cohérence automatique + +À chaque création/mise à jour d'un projet, la Console synchronise automatiquement +les policies et les groupes d'identité Vault du projet. + +L'opération est **idempotente**. La suppression de projet retire le mount et les groupes associés. + +--- + +## 5. 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. + +--- + +## 6. Références + +- Fiche « Provisionnement automatique par la Console » (ce dossier) — vue d'ensemble. +- Fiche « Secrets Vault et … » (et équivalents) — tokens & miroir. +- **Matrice RBAC** (groupes Keycloak ↔ droits par outil) : ADR « Gestion des droits fins ».