Rôles

À quoi sert cet écran

Un rôle est un intitulé de poste composé de policies. C’est la seule chose que l’on attribue à un utilisateur, et c’est là que la chaîne permission → policy → rôle → utilisateur devient visible : les rôles ne portent aucune permission en propre, ils portent des policies, et ce sont les policies qui portent les permissions.

Trois rôles sont livrés avec chaque installation — Admin, Developer, DevOps — et vous pouvez en créer autant que nécessaire.

Avant de commencer

Pour faire ceci	Il vous faut
Voir l’onglet	`platform-settings.role.read`
Créer un rôle	`platform-settings.role.create`
Modifier un rôle	`platform-settings.role.update`
Supprimer un rôle	`platform-settings.role.delete`

Créez d’abord les policies. Un rôle sans policy est valide et n’accorde rien.

Ouvrir l’écran

Settings › People & Access
Sélectionnez l’onglet Roles.

La création et la modification d’un rôle ouvrent une page entière plutôt qu’une boîte de dialogue : /platform-settings/roles/new et /platform-settings/roles/edit/:roleId.

L’interface

📸 Capture d’écran : La page d’édition d’un rôle. Repères : (1) le champ du nom, (2) le champ de description, (3) la section Permission Policies avec sa zone de recherche, (4) la ligne indiquant le nombre de policies sélectionnées, (5) le bouton Save.

#	Élément	Ce qu’il fait	Quand l’utiliser
1	Nom du rôle	Le nom sous lequel il est attribué	Toujours
2	Description	Ce à quoi sert le rôle	À remplir : c’est le seul endroit où l’intention est consignée
3	Liste de policies avec recherche	Choisit les policies portées par le rôle	Le cœur du rôle
4	Nombre sélectionné	Combien de policies sont rattachées	Contrôle avant enregistrement
5	Save	Écrit le rôle et ses statements	Pour terminer

Le rôle admin n'est pas un assemblage de policies

Lorsque le rôle s’appelle admin, l’éditeur remplace la liste de policies par un avertissement : le rôle administrateur dispose d’un accès complet automatique à toutes les fonctionnalités, permissions, clusters et environnements, y compris ceux ajoutés à l’avenir. Attribuer admin n’est pas un raccourci pour « beaucoup d’accès » : c’est un accès sans portée, permanent, et qui s’élargit tout seul à mesure que la plateforme grandit. Construisez plutôt un rôle cantonné.

Procédures

Créer un rôle

Nécessite platform-settings.role.create.

Settings › People & Access › Roles, cliquez sur Add Role.
Nommez-le d’après le poste, pas d’après la personne.
Rédigez une description précisant les environnements et clusters visés. C’est la seule trace de l’intention, et c’est ce que lira le prochain administrateur.
Dans Permission Policies, recherchez et sélectionnez les policies à rattacher.
Vérifiez le nombre sélectionné, puis Save.

Modifier ce qu’accorde un rôle

Nécessite platform-settings.role.update.

Ouvrez le rôle depuis l’onglet Roles.
Ajoutez ou retirez des policies, puis enregistrez.

Tous les utilisateurs détenant ce rôle sont affectés immédiatement, dès leur requête suivante — un rechargement peut être nécessaire pour voir les changements de menu. Modifier un rôle largement attribué est le moyen le plus rapide de changer l’accès de beaucoup de monde, et aussi le plus simple de le retirer à des personnes auxquelles vous ne pensiez pas. Vérifiez d’abord qui le détient.

Supprimer un rôle

Nécessite platform-settings.role.delete.

Vérifiez qui le détient avant de supprimer. Les utilisateurs ne sont pas supprimés avec lui : ils perdent simplement ce que ce rôle accordait.

Scénario

Un accès en lecture seule pour un auditeur, pendant deux semaines.

Un auditeur externe doit consulter les déploiements et la configuration sur staging, sans rien pouvoir modifier.

Policies — créez Audit Read en ne sélectionnant que des permissions .read. Cantonnez le statement au cluster de staging et à l’environnement staging.
Rôles — créez Auditor, description : « Lecture seule sur staging. Temporaire — à retirer après l’audit. » N’y rattachez que Audit Read.
Utilisateurs — créez le compte de l’auditeur avec le rôle Auditor et le profil Dev.
Vérifiez dans Access Explorer qu’une permission d’écriture est bien refusée pour lui. Ne vérifiez pas en demandant à l’auditeur d’essayer.
Après l’audit, supprimez l’utilisateur. Conservez le rôle : il ne coûte rien et sera prêt pour le prochain.

Résister à la tentation d’attribuer admin « juste pour deux semaines » est tout l’intérêt de ce scénario : admin ne peut pas être cantonné, et il récupère silencieusement tout cluster ajouté tant que l’auditeur possède un compte.

En cas de problème

Symptôme	Cause	Comment vérifier	Solution
Rôle attribué, l’utilisateur ne peut toujours rien faire	Le rôle ne porte aucune policy	Ouvrez le rôle et lisez le nombre sélectionné	Rattachez au moins une policy
Le rôle accorde plus que prévu	Une de ses policies n’a pas de portée	Ouvrez chaque policy et vérifiez ressources et conditions	Cantonnez le statement à des clusters et environnements précis
Pas de liste de policies à l’édition	Le rôle s’appelle `admin` et dispose d’un accès complet automatique	L’avertissement dans l’éditeur	Comportement attendu ; créez un autre rôle pour un accès cantonné
L’enregistrement échoue	Une erreur s’affiche en haut de l’éditeur	Lisez le message	Corrigez et réessayez ; rien n’est écrit en cas d’échec
Retirer une policy n’a pas réduit l’accès	Un autre rôle détenu par l’utilisateur l’accorde encore	Access Explorer sur cet utilisateur	Vérifiez tous ses rôles, pas seulement celui que vous avez modifié

Pour aller plus loin

Policies — là où vivent réellement les permissions et le cantonnement
Access Explorer — vérifiez un rôle avant de lui faire confiance