Docs

Personnes et accès

À quoi sert cet écran

Personnes et accès détermine qui a le droit de faire quoi. Cet espace comporte quatre onglets qui s’appuient l’un sur l’autre : vous créez des policies (des ensembles de permissions, éventuellement limités à certains clusters et environnements), vous les regroupez en rôles, vous attribuez les rôles à des utilisateurs, et vous utilisez les groupes pour organiser ces utilisateurs.

Rien ici n’accorde une permission directement à une personne. L’accès suit toujours la chaîne permission → policy → rôle → utilisateur, et l’erreur la plus fréquente consiste à vouloir sauter un maillon.

Avant de commencer

Onglet Permission de lecture Permissions de modification
Users platform-settings.user.read .user.create .user.update .user.delete .user.assign-group
Groups platform-settings.group.read .group.create .group.update .group.delete .group.view-details
Roles platform-settings.role.read .role.create .role.update .role.delete
Policies platform-settings.permission-policy.read .permission-policy.create .update .delete

Un onglet que vous ne pouvez pas lire n’est pas affiché. Les boutons des actions que vous ne pouvez pas effectuer sont masqués ou désactivés plutôt que d’échouer au clic.

Ouvrir l’écran

  1. Cliquez sur Settings dans la barre latérale.
  2. Cliquez sur People & Access.

URL directe : /platform-settings/access

L’interface

📸 Capture d’écran : La page People & Access avec les quatre onglets en haut et le tableau Users en dessous. Repères : (1) la barre d’onglets, (2) le bouton Add User, (3) le champ de recherche, (4) les icônes d’action de chaque ligne.

# Élément Ce qu’il fait Quand l’utiliser
1 Barre d’onglets — Users · Groups · Roles · Policies Bascule entre les quatre registres Selon la tâche ; voir l’ordre ci-dessous
2 Bouton Add Ouvre la boîte de dialogue de création de l’onglet courant Ajouter un utilisateur, un groupe, un rôle ou une policy
3 Champ de recherche Filtre le tableau courant Dès que la liste dépasse un écran
4 Icônes d’action Modifier et supprimer la ligne Modifier ou retirer une entrée

Procédures

Les quatre onglets s’utilisent dans un ordre précis lorsqu’on part de zéro, car chacun consomme ce que le précédent a produit :

  1. Policies — définissez un ensemble de permissions, et les clusters et environnements auxquels il s’applique.
  2. Rôles — regroupez les policies sous un intitulé de poste.
  3. Utilisateurs — créez la personne et attribuez-lui le rôle.
  4. Groupes — organisez les personnes pour la propriété et la visibilité.

Procéder dans l’autre sens produit le fameux « j’ai créé l’utilisateur mais il ne peut toujours rien faire ».

Scénario

Sarah arrive comme développeuse backend. Elle doit pouvoir déployer en dev, mais pas en production.

Ce scénario traverse les quatre onglets, ce qui en fait le meilleur à retenir.

  1. Policies — créez Dev Deploy. Ajoutez les permissions de déploiement, puis cantonnez le statement : sélectionnez le cluster de dev dans les ressources et fixez la condition d’environnement à dev. Le cantonnement est tout l’enjeu : une policy de déploiement sans portée accorde aussi la production.
  2. Rôles — créez Backend Developer et affectez-lui la policy Dev Deploy. N’attribuez pas le rôle admin comme raccourci : admin contourne entièrement les policies et accorde tout, y compris les clusters ajoutés plus tard.
  3. Utilisateurs — cliquez sur Add User. Saisissez le nom d’utilisateur GitHub ou Bitbucket exact de Sarah et l’e-mail de ce compte. Attribuez-lui le rôle Backend Developer. Réglez son profil sur Dev.
  4. Sarah se connecte via GitHub. Fenwave crée son profil à la première connexion : elle ne s’inscrit pas et ne peut pas modifier son propre compte.
  5. Groupes — ajoutez-la au groupe Backend pour que l’équipe soit propriétaire de ses composants.
  6. Vérifiez avec Access Explorer : recherchez Sarah et confirmez que la permission de déploiement en dev est autorisée et que celle de production ne l’est pas.

L’étape 6 n’est pas facultative en pratique. Les erreurs de portée sont silencieuses : une policy trop large est visuellement identique à une policy correcte, jusqu’au jour où quelqu’un déploie en production.

En cas de problème

Symptôme Cause Comment vérifier Solution
Utilisateur créé, mais il ne peut rien faire Aucun rôle attribué, ou le rôle ne porte aucune policy Access Explorer sur cet utilisateur Attribuez un rôle portant au moins une policy
L’utilisateur ne peut pas se connecter L’e-mail ne correspond pas à son compte OAuth Comparez avec son profil GitHub/Bitbucket Corrigez l’e-mail : la correspondance doit être exacte
Permission accordée mais le menu n’a pas changé Les résultats de permissions sont mis en cache pour la session Demandez à l’utilisateur de recharger Rechargez la page
Un utilisateur atteint la production alors que la policy dit dev Le statement n’a pas été cantonné Ouvrez la policy et vérifiez ressources et conditions Ajoutez la ressource cluster et la condition d’environnement
Un onglet est absent Il vous manque sa permission de lecture Access Explorer sur vous-même Demandez un rôle qui l’accorde

Pour aller plus loin