ÉQUIPE & ACCÈS

Rôles et permissions

Les deux catalogues de permissions, les rôles fournis, et comment construire un rôle sur mesure.

DockBoard possède deux systèmes de permissions, délibérément séparés. Les permissions de projet décident de ce que vous pouvez faire dans un projet. Les permissions de plateforme décident de ce que vous pouvez faire à l’installation. On peut être administrateur complet de son propre projet et ne rien détenir au niveau plateforme.

Permissions de projet

Une permission est une chaîne ressource:action. view lit ; manage — ou un verbe plus fin — modifie. Les verbes fins existent pour qu’un rôle puisse accorder « peut déployer mais pas supprimer » :

Ressource	Actions
`apps`	`view` `create` `deploy` `restart` `delete` `env` `exec` `logs`
`databases`	`view` `create` `manage` `delete`
`instances`	`view` `create` `manage` `ssh` `delete`
`domains`	`view` `manage` `delete`
`backups`	`view` `create` `restore` `delete`
`files`, `sftp`, `email`, `protection`, `quotas`	`view` `manage` (`quotas` accorde `view` largement, `manage` étroitement)
`monitoring`, `deployments`	`view`
`marketplace`	`install`

Trois d’entre elles méritent d’être signalées, parce qu’elles portent plus loin qu’il n’y paraît :

apps:env: Lit et écrit les variables d’environnement — des secrets de production. Volontairement absente du rôle en lecture seule : voir une application n’implique pas voir ses identifiants.
apps:exec: Ouvre un shell dans le conteneur. Ce shell peut lire tout l’environnement : cette permission implique donc tout ce qu’accorde apps:env, que vous l’ayez accordée ou non.
instances:ssh: Un shell root sur une instance Linux. Séparée de manage pour qu’un rôle puisse accorder redémarrage et redimensionnement sans shell sur la machine.

Les quatre rôles fournis

Rôle	Détient
VIEWER	Toutes les permissions `:view`, rien d’autre. Lit tout, ne modifie rien, et ne voit jamais les secrets.
DEVELOPER	Toute la surface de construction et de livraison : applications, domaines, bases, fichiers, SFTP, sauvegardes, installations marketplace, protection par application. Voit le quota du projet sans pouvoir le modifier. Aucune administration des membres ni des rôles.
ADMIN	Toutes les permissions fines, plus l’administration des membres et des rôles et les réglages du projet.
OWNER	ADMIN, plus les deux actions réservées au propriétaire : supprimer le projet et le transférer.

Rôles personnalisés

Un rôle personnalisé est n’importe quel sous-ensemble de la grille ci-dessus, enregistré sous un nom à vous. Partez d’un préréglage fourni et ajustez. Les formes réellement construites :

Un déployeur — apps:view, apps:deploy, deployments:view. Livre du code, ne peut ni lire les secrets ni rien supprimer.
Un exploitant de bases — les verbes databases et backups, rien sur les applications.
Un compte support — tous les :view sauf apps:env, pour diagnostiquer sans détenir vos identifiants.

Quatre capacités ne sont jamais délégables à un rôle personnalisé : supprimer le projet, le transférer, gérer les membres et modifier les rôles. Une grille de permissions capable d’accorder « modifier les rôles » pourrait s’accorder tout le reste en une étape, ce qui rendrait la grille entière décorative.

Un rôle personnalisé porte un rang de base. Il peut élever les droits fins d’un membre, mais jamais son rang administratif au-dessus de cette base — un rôle personnalisé bâti sur DEVELOPER ne peut donc pas devenir administrateur en accumulant des permissions.

Permissions de plateforme

Un second catalogue indépendant protège la console Admin : users, projects, servers, config, updates, audit, docker, monitoring, quotas, license — chacun avec view et manage, plus users:assist pour les réinitialisations de mot de passe et réactivations sans autorité complète sur les comptes.

Quatre préréglages couvrent les cas usuels :

Complet: Tout, énoncé explicitement.
Support: Voir et assister les utilisateurs ; lecture seule sur les projets et le journal d’audit.
Infra: Serveurs, Docker, supervision. Aucune autorité sur les comptes ni la configuration.
Lecture seule: Voit tout, ne change rien.

Résolution, dans l’ordre : un SUPERADMIN détient toujours tout. Un administrateur avec une grille personnelle détient exactement cette grille. Un administrateur avec un rôle d’administration attribué détient la grille de ce rôle. Un administrateur sans ni l’un ni l’autre détient tout — ainsi les installations existantes continuent de fonctionner, et restreindre un administrateur est un acte explicite plutôt qu’un effet de bord silencieux d’une mise à jour.

license:manage est une ressource distincte plutôt qu’une partie de config. Retirer la clé rétrograde toute l’installation vers l’offre gratuite — toutes les fonctionnalités Pro coupées, pour tous les utilisateurs, d’un coup — et un support ou un exploitant infra n’a aucune raison d’y toucher.

Une clé API est bornée par les deux systèmes à la fois : elle ne peut jamais dépasser les permissions de son propriétaire, et ses propres scopes la restreignent davantage. Deux plafonds, et c’est toujours le plus bas qui l’emporte.