Comment fonctionnent les permissions

À quoi sert cet écran

Cette page n’est pas un écran : c’est le modèle qui sous-tend les quatre onglets de Personnes et accès. Lisez-la une fois et le reste des Paramètres cesse de surprendre.

Fenwave utilise un contrôle d’accès basé sur les rôles (RBAC). L’accès suit une seule chaîne, et chaque onglet de Personnes et accès en est un maillon :

permission  →  policy  →  rôle  →  utilisateur

Avant de commencer

Rien à configurer. Pour appliquer le modèle, il vous faut les permissions listées sur Personnes et accès.

Ouvrir l’écran

Il n’y a rien à ouvrir. Les concepts décrits ici apparaissent dans Policies, Rôles, Utilisateurs et Access Explorer.

L’interface

Les quatre maillons de la chaîne

On n’accorde jamais une permission à une personne. Si quelqu’un a besoin d’un accès, la question est toujours quel rôle, puis quelle policy dans ce rôle.

Nommage des permissions

<plugin>.<ressource>.<action> — par exemple platform-settings.cluster.validate.

Les actions sont généralement read, create, update, delete, auxquelles s’ajoutent des verbes propres à la ressource : validate sur les identifiants, export et import sur la configuration, assign-group sur les utilisateurs, assign-owner et manage-components sur les projets, view-details sur les groupes et les projets.

Copiez les chaînes de permission à l’identique. Access Explorer les compare littéralement.

Types de permissions et profils

Les permissions portent un type :

• default — accessible aux deux profils.
• devops — utilisable uniquement par un profil DevOps.

Chaque utilisateur possède un profil, Dev ou DevOps, renseigné explicitement sur sa fiche. Il n’est pas déduit des permissions détenues. Le profil a deux effets :

1. Il filtre les rôles. Un utilisateur de profil Dev ne peut pas recevoir un rôle marqué DevOps ; le rôle est affiché avec la mention « requires DevOps profile ».
2. Il choisit la réserve de sièges de licence. Les sièges Dev et DevOps sont comptés séparément, et un utilisateur sans profil renseigné compte comme dev.

Cantonnement

Le cantonnement vit sur le statement de la policy, nulle part ailleurs. Un statement peut restreindre ses permissions à :

• des clusters — choisis comme ressources ;
• des environnements — dev, staging, production, sous forme de condition ; un ou plusieurs.

Un statement qui n’a ni l’un ni l’autre s’applique partout. C’est la mauvaise configuration la plus fréquente dans Fenwave, et elle est silencieuse : dans la liste, une policy trop large est identique à une policy correcte.

Noms de permissions cantonnés par environnement

Les permissions env-by-branch.* existent sous deux formes, et le backend passe de l’une à l’autre. Un nom plat comme env-by-branch.devops-config.read est contrôlé comme env-by-branch.dev.devops-config.read, puis staging, puis production, puis le nom plat lui-même. Détenir une seule variante d’environnement satisfait une route à nom plat pour cet environnement.

env-by-branch.platform-service.* est volontairement indépendant de l’environnement et n’est jamais étendu.

Procédures

Comprendre pourquoi quelqu’un ne peut pas faire quelque chose

1. Ouvrez Access Explorer.
2. Recherchez l’utilisateur et la chaîne de permission exacte.
3. Lisez le résultat le long de la chaîne :
   • Refusé et aucun rôle ne l’accorde → attribuez un rôle portant une policy qui l’accorde.
   • Autorisé ici mais en échec dans le produit → vérifiez le cantonnement : la policy ne couvre peut-être pas ce cluster ou cet environnement.
   • Autorisé et le menu reste invisible → cache de session ; rechargez.

Accorder un accès sans trop accorder

1. Partez de la policy la plus étroite qui fasse le travail.
2. Cantonnez le statement aux clusters et environnements précis.
3. Rattachez-la à un rôle dédié à ce poste.
4. Vérifiez dans Access Explorer avant d’annoncer à l’utilisateur que c’est fait.

Scénario

« Marc peut déployer en production et personne ne sait pourquoi. »

Marc est un développeur qui ne devrait atteindre que le dev.

1. Access Explorer sur marc et la permission de déploiement en production → autorisé. C’est donc accordé, ce n’est pas une anomalie.
2. Regardez les rôles de Marc. Il détient Backend Developer et On-Call.
3. Ouvrez les policies de chacun. Backend Developer est correctement cantonné au dev. On-Call contient un statement sans condition d’environnement.
4. Ce statement sans portée est la cause. Les permissions sont cumulatives : c’est l’union de tous les rôles qui s’applique, un rôle correctement cantonné ne peut donc pas retirer ce qu’un autre accorde.
5. Corrigez la policy On-Call en ajoutant la condition d’environnement production et la ressource cluster, plutôt que de retirer Marc du rôle.
6. Revérifiez dans Access Explorer.

La leçon se généralise : quand un accès est trop large, auditez tous les rôles de l’utilisateur. Restreindre celui que vous soupçonniez ne suffit jamais à lui seul.

En cas de problème

Pour aller plus loin

• Policies — là où le cantonnement s’applique
• Access Explorer — l’outil qui répond à « pourquoi pas ? »