Accès et permissions

Deux notions distinctes coexistent :

• Accès Applications — qui peut utiliser une application déployée (se connecter à Digdash BI, à Hop…) ;
• Permissions Internes — qui peut administrer quoi dans le Control Panel lui-même.

Accès Applications

La page Accès Applications (ou le bouton Gérer les accès d'une carte, non disponible pour PostgreSQL) liste, pour chaque application à authentification OIDC, tous les utilisateurs de la plateforme séparés en deux sections Avec accès / Sans accès, avec recherche et sélection multiple pour agir en masse sur plusieurs utilisateurs à la fois.

Deux mécanismes selon le modèle, affichés automatiquement par la page :

• Profils (la majorité des modèles, ex. Digdash BI) : octroyer l'accès consiste à attribuer un ou plusieurs profils (rôles applicatifs) à l'utilisateur — un utilisateur sans profil n'a pas accès. Le bouton Ajouter profils ouvre la sélection, individuellement ou en masse sur la sélection courante.
• Accorder / révoquer direct (Apache Hop GUI uniquement) : un simple octroi binaire, sans notion de profil — boutons Accorder / Révoquer, également disponibles en masse.

Permissions Internes

Les rôles du Control Panel se donnent par namespace (l'utilisateur agit sur tout le namespace, depuis l'onglet Namespaces) ou par application (portée limitée à une seule application, depuis cette page). La page Permissions Internes reprend la même interface que Accès Applications (recherche, sections Avec/Sans permission, sélection multiple pour les actions en masse), mais n'affiche et ne modifie que les permissions posées directement sur l'application : les rôles hérités du namespace n'y apparaissent pas — un rappel que l'écran affiche lui-même, avec le tableau des droits ci-dessous. Toutes les applications du namespace y figurent, y compris celles sans connexion Keycloak (PostgreSQL, Apache Iceberg, Nginx, Spark Connect…), absentes de la page Accès Applications faute d'accès à y octroyer.

Rôle	Ce qu'il permet
viewer	Voir les applications, volumes, buckets du périmètre
operator	+ démarrer/arrêter/redémarrer, mettre à jour une application, configurer, resynchroniser
admin	+ déployer et supprimer, gérer les accès et permissions du périmètre

S'y ajoute le statut administrateur de plateforme, transversal : gestion des utilisateurs, des groupes, des namespaces et quotas, des paramètres cluster, de l'instance Git et de l'authentification relais.

Droit de création de namespaces

Créer un namespace ne demande plus d'être administrateur de plateforme. Le droit Création de namespaces peut être accordé :

• à un utilisateur, dans sa fiche (Utilisateurs → Modifier l'utilisateur), à sa création, ou par la colonne creation_namespaces de l'import en masse ;
• à un groupe : tous ses membres le reçoivent, tant qu'ils en font partie.

La personne qui crée un namespace en devient administrateur (admin) — de celui-là seulement. Le droit ne donne rien d'autre : ni la suppression d'un namespace, qui reste réservée à l'administrateur de plateforme, ni la gestion des groupes ou des paramètres cluster. Comme tout administrateur de namespace, elle peut créer des comptes utilisateurs, mais pas les modifier ni les supprimer. Seul un administrateur de plateforme peut l'accorder.

Dans la liste des Utilisateurs, un badge signale les titulaires du droit ; au survol, il indique s'il vient d'un groupe. Un administrateur de plateforme le possède d'office.

Groupes

Réservé aux administrateurs de plateforme.

Un groupe est un ensemble d'utilisateurs. Tout ce qui est accordé au groupe s'applique à chacun de ses membres, tant qu'il en est membre : quitter le groupe retire ce que le groupe apportait, et seulement cela.

Ce qu'un groupe peut porter

Élément	Ce que reçoivent les membres	Application
Accès à une application (et ses profils, pour Digdash BI et NiFi)	Le droit de se connecter à l'application, avec ces profils	Poussé dans Keycloak
Rôle sur un namespace	viewer, operator ou admin sur tout le namespace	Immédiat
Rôle sur une application	Un rôle limité à cette application	Immédiat
Création de namespaces	Le droit de créer des namespaces	Immédiat

Les rôles et le droit de création sont calculés à chaque action : un changement est effectif aussitôt. L'accès aux applications, lui, doit être inscrit dans Keycloak (voir Quand les changements s'appliquent).

Comment les droits se combinent

Un utilisateur peut recevoir des droits de plusieurs sources : en direct et par un ou plusieurs groupes. Rien ne s'écrase :

• Rôles : le plus élevé l'emporte. Un rôle posé sur une application prime sur le rôle du namespace qui la contient.
• Accès et profils : ils s'additionnent. Un membre de deux groupes reçoit l'union de leurs profils, plus ceux qui lui sont attribués directement. Un accès reste en place tant qu'au moins une source le justifie : retirer quelqu'un d'un groupe ne lui enlève pas un accès qu'il tient aussi en direct ou par un autre groupe.

Quand les changements s'appliquent

• Ajouter ou retirer un membre : ses accès sont mis à jour immédiatement.
• Associer ou dissocier une application, changer ses profils, supprimer le groupe : le changement est enregistré aussitôt puis appliqué à tous les membres par une tâche de fond, dont la progression s'affiche sur la page. Sur un groupe de plusieurs milliers de membres, cela prend quelques minutes. En cas d'échec partiel, le bouton Resynchroniser repousse l'accès et les profils à tous les membres.
• Réconciliation périodique : la tâche système de réconciliation rétablit dans Keycloak les accès que les groupes justifient mais qui manqueraient. Elle ne retire jamais rien — plusieurs Control Panel peuvent partager le même Keycloak, et un accès sans justification ici peut en avoir une ailleurs.

Accès applicatifs et profils

Seules les applications démarrées sont proposées à l'association : rien ne pourrait être appliqué à une application arrêtée. Pour Digdash BI et Apache NiFi, le bouton Profils d'une application associée permet de choisir les profils que le groupe confère ; les autres applications restent en accès simple.

Ce qui vient d'un groupe apparaît grisé

Sur la page Accès Applications, les profils hérités d'un groupe sont affichés grisés, avec le nom du groupe au survol, et un badge « via groupe » signale les utilisateurs concernés. Dans Modifier les profils, ils sont cochés mais non décochables : les retirer à cet endroit n'aurait aucun effet, le groupe les réattribuerait. De même, Révoquer est désactivé pour un utilisateur qui ne tient son accès que d'un groupe. Ces accès se retirent depuis la page Groupes.

Noms de groupe

Un nom de groupe est unique sans tenir compte des majuscules : « Metier » et « metier » désignent le même groupe. L'import en masse rattache donc un utilisateur au groupe existant quelle que soit la casse, et ne crée un groupe que s'il n'existe vraiment pas.

Note

Les permissions du Control Panel sont indépendantes des rôles internes de chaque application : donner operator sur un namespace n'accorde pas, par exemple, des droits d'administration dans Digdash BI lui-même.