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/reader	Lister environnements et dépôts uniquement
Lecture seule (administration)	/console/reader	Lecture transverse (tous projets)
Security (projet)	/<slug>/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 /<slug>/console/*.

Rôle Console	Groupe Keycloak	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	MANAGE_REPOSITORIES, LIST_ENVIRONMENTS, LIST_REPOSITORIES
Lecture seule	/<slug>/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 /<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.
• /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