Comprendre les rôles personnalisés d'IAM

La gestion de l'authentification et des accès (IAM) fournit des rôles prédéfinis qui accordent un accès précis à des ressources Google Cloud spécifiques et empêchent les accès indésirables à d'autres ressources.

IAM permet également de créer des rôles IAM personnalisés. Vous pouvez créer un rôle IAM personnalisé avec une ou plusieurs autorisations, puis attribuer ce rôle personnalisé aux utilisateurs. Cloud IAM fournit une interface utilisateur et une API pour la création et la gestion des rôles personnalisés.

Cette rubrique ne fournit pas une liste complète de toutes les autorisations IAM que vous pouvez inclure dans vos rôles personnalisés. Pour vérifier si une autorisation spécifique est compatible avec les rôles personnalisés, consultez la section Niveau de compatibilité des autorisations dans les rôles personnalisés.

Avant de commencer

Concepts fondamentaux

Dans IAM, vous n'accordez pas directement d'autorisations aux utilisateurs. À la place, vous leur accordez des rôles englobant une ou plusieurs autorisations. Il existe plusieurs types de rôles dans IAM : les rôles de base, les rôles prédéfinis et les rôles personnalisés.

Les rôles de base incluent trois rôles qui existaient avant le lancement d'IAM : "Propriétaire", "Éditeur" et "Lecteur".

Les rôles prédéfinis sont créés et gérés par Google. Leurs autorisations sont automatiquement mises à jour si nécessaire, par exemple lorsque de nouvelles fonctionnalités ou de nouveaux services sont ajoutés à Google Cloud.

Les rôles personnalisés sont définis par l'utilisateur et permettent de grouper une ou plusieurs autorisations compatibles pour répondre à vos besoins spécifiques. Les rôles personnalisés ne sont pas gérés par Google. Lorsque de nouvelles autorisations, fonctionnalités ou services sont ajoutés à Google Cloud, vos rôles personnalisés ne sont pas mis à jour automatiquement.

Lorsque vous créez un rôle personnalisé, vous devez choisir l'organisation ou le projet dans lequel vous allez le créer. Vous pouvez ensuite attribuer le rôle personnalisé au niveau de l'organisation ou du projet choisis et de leurs ressources.

Pour créer un rôle personnalisé, vous devez combiner une ou plusieurs autorisations IAM disponibles. Les autorisations permettent aux utilisateurs d'effectuer des actions spécifiques sur les ressources Google Cloud. Dans le monde IAM, les autorisations sont représentées sous la forme suivante :

service.resource.verb

Par exemple, l'autorisation compute.instances.list permet à un utilisateur de répertorier les instances Compute Engine dont il est propriétaire, tandis que compute.instances.stop lui permet d'arrêter une VM.

Les autorisations correspondent généralement, mais pas toujours, 1:1 aux méthodes REST. Autrement dit, chaque service Google Cloud possède une autorisation associée pour chaque méthode REST dont il dispose. Pour appeler une méthode, l'appelant a besoin de cette autorisation. Par exemple, l'appelant de topic.publish() a besoin de l'autorisation pubsub.topics.publish.

Vous ne pouvez attribuer un rôle personnalisé qu'au sein du projet ou de l'organisation dans laquelle vous l'avez créé. Vous ne pouvez pas attribuer de rôles personnalisés sur d'autres projets ou organisations, ni sur des ressources appartenant à d'autres projets ou organisations.

Autorisations et rôles requis

Pour créer un rôle personnalisé, l'appelant doit disposer de l'autorisation iam.roles.create.

Les utilisateurs non propriétaires, y compris les administrateurs de l'entreprise, doivent se voir attribuer le rôle Administrateur des rôles de l'entreprise (roles/iam.organizationRoleAdmin) ou le rôle Administrateur des rôles IAM roles/iam.roleAdmin. Le rôle Examinateur de sécurité IAM (roles/iam.securityReviewer) permet d'afficher les rôles personnalisés, mais pas de les gérer. Pour savoir comment attribuer ces rôles, consultez la page Accorder, modifier et révoquer les accès.

L'interface utilisateur des rôles personnalisés se trouve dans Google Cloud Console sous "Rôles IAM". Elle est uniquement disponible pour les utilisateurs disposant des autorisations requises pour créer ou gérer des rôles personnalisés. Par défaut, seuls les propriétaires de projet peuvent créer des rôles. Les propriétaires de projet peuvent contrôler l'accès à cette fonctionnalité en attribuant le rôle Administrateur de rôle IAM à d'autres personnes du même projet. Pour les entreprises, seuls les administrateurs d'entreprise peuvent attribuer le rôle d'administrateur de rôle d'entreprise.

Les rôles d'administration sont décrits plus en détail ci-dessous.

Rôle Administrateur des rôles de l'organisation

Si une entreprise est associée à votre compte Google Cloud, le rôle Administrateur des rôles de l'organisation vous permet de gérer tous les rôles personnalisés de votre entreprise. Il ne peut être accordé qu'au niveau de l'organisation. Seuls les administrateurs d'entreprise peuvent attribuer le rôle Administrateur des rôles de l'organisation.

Le tableau suivant répertorie les autorisations du rôle Administrateur des rôles de l'organisation :

Rôle Autorisations
roles/iam.organizationRoleAdmin iam.roles.create
iam.roles.delete
iam.roles.undelete
iam.roles.get
iam.roles.list
iam.roles.update
resourcemanager.projects.get
resourcemanager.projects.getIamPolicy
resourcemanager.projects.list
resourcemanager.organizations.get
resourcemanager.organizations.getIamPolicy

Rôle Administrateur des rôles

Le rôle Administrateur des rôles vous permet de gérer tous les rôles personnalisés d'un projet. Utilisez ce rôle si vous n'avez pas d'entreprise. Ce rôle peut uniquement être attribué au niveau du projet par les propriétaires du projet ou de l'entreprise.

Le tableau suivant répertorie les autorisations du rôle Administrateur des rôles :

Rôle Autorisations
roles/iam.roleAdmin iam.roles.create
iam.roles.delete
iam.roles.undelete
iam.roles.get
iam.roles.list
iam.roles.update
resourcemanager.projects.get
resourcemanager.projects.getIamPolicy

Cycle de vie des rôles personnalisés

Quelques concepts s'appliquent lors du choix de la modélisation, de la création et de la gestion de vos rôles personnalisés.

Création

Avant de décider de créer un rôle personnalisé, assurez-vous qu'il n'existe pas déjà un rôle (ou un ensemble de rôles) prédéfini pour le service répondant à vos besoins. Pour obtenir une liste complète des rôles prédéfinis, ainsi que des autorisations incluses dans chaque rôle prédéfini, consultez la documentation de référence sur les rôles prédéfinis.

Si aucun rôle prédéfini ou ensemble de rôles prédéfinis ne répond à vos besoins, vous pouvez créer un rôle personnalisé qui n'inclut que les autorisations à accorder. Pour plus d'informations, consultez la section Créer et gérer les rôles personnalisés.

Autorisations non disponibles ou non compatibles

Certaines autorisations peuvent ne pas s'afficher ou être utilisées dans un rôle personnalisé. Par exemple, une autorisation peut ne pas être disponible pour des rôles personnalisés si le service est en version bêta ou si vous n'avez pas activé l'API pour le service.

Pour vérifier si vous pouvez utiliser une autorisation spécifique dans les rôles personnalisés, consultez la section Niveau de compatibilité des autorisations dans les rôles personnalisés. Pour connaître les autorisations que vous pouvez utiliser avec une ressource spécifique, consultez la section Afficher des autorisations disponibles pour une ressource.

Dépendances d'autorisation

Certaines autorisations ne sont efficaces que si elles sont accordées par paires. Par exemple, pour mettre à jour une stratégie IAM, vous devez utiliser le modèle lecture-modification-écriture. Par conséquent, pour mettre à jour une stratégie, vous avez presque toujours besoin de l'autorisation getIamPolicy pour ce service et ce type de ressource, en plus de l'autorisation setIamPolicy.

Pour vous assurer de l'efficacité des rôles personnalisés, vous pouvez les créer à partir de rôles prédéfinis qui fournissent des autorisations similaires. Les rôles prédéfinis peuvent vous aider à identifier les autorisations généralement utilisées conjointement.

Pour savoir comment créer un rôle personnalisé basé sur un rôle prédéfini, consultez la page Créer et gérer des rôles personnalisés.

Nommer le rôle

Les rôles possèdent à la fois un ID et un titre. L'ID est un identifiant unique pour le rôle. Le titre apparaît dans la liste des rôles dans Cloud Console.

Les ID de rôle doivent être uniques au sein du projet ou de l'organisation dans lequel vous avez créé les rôles. Cela permet de garantir que l'ID complet d'un rôle, qui inclut son projet ou son organisation, reste unique. Les ID de rôle peuvent comporter jusqu'à 64 caractères alphanumériques en majuscules et minuscules, pouvant également contenir des traits de soulignement et des points.

Vous ne pouvez pas modifier les ID de rôle. Réfléchissez donc bien avant de les choisir. Il est possible de supprimer un rôle personnalisé, mais pas de créer un autre rôle personnalisé portant le même ID complet avant la fin du processus de suppression de 37 jours. Pour en savoir plus sur le processus de suppression, consultez la page Supprimer un rôle personnalisé.

Le titre d'un rôle personnalisé ne doit pas nécessairement être unique. Ainsi, Cloud Console peut afficher plusieurs rôles personnalisés dont le titre est identique. Afin d'éviter toute confusion, utilisez des noms uniques et descriptifs pour vos rôles personnalisés. Pensez également à indiquer dans le titre du rôle s'il s'agit d'un rôle attribué au niveau de l'organisation ou du projet.

Les titres de rôle peuvent comporter jusqu'à 100 octets et contenir des caractères alphanumériques en majuscules et minuscules. Vous pouvez modifier les titres des rôles à tout moment.

Description du rôle

Pensez à mettre à jour la description du rôle après la modification d'un rôle personnalisé, et incluez à la fois la date de modification et un résumé de la finalité du rôle. Les descriptions peuvent comporter jusqu'à 256 caractères et contenir des symboles et des caractères alphanumériques en majuscules et minuscules.

Tester et déployer

Les rôles personnalisés incluent une étape de lancement, qui est stockée dans la propriété stage du rôle. La phase de lancement est informative. Elle vous permet de savoir si chaque rôle est prêt à être utilisé à grande échelle.

Chaque rôle personnalisé peut comporter l'une des étapes de lancement suivantes :

Étapes de lancement
ALPHA Le rôle est toujours en cours de développement ou de test, ou il inclut des autorisations pour des services ou des fonctionnalités Google Cloud qui ne sont pas encore publics. Il n'est pas prêt à être utilisé à grande échelle.
BETA Le rôle a été testé de façon limitée ou inclut des autorisations pour des services ou des fonctionnalités Google Cloud qui ne sont pas accessibles à tous.
GA Le rôle a été largement testé et toutes ses autorisations concernent des services ou des fonctionnalités Google Cloud accessibles à tous.

Lorsque vous créez un rôle personnalisé, définissez l'étape de lancement sur ALPHA. Demandez à quelques membres de votre entreprise de tester le rôle. Une fois que vous êtes assuré que le rôle personnalisé fonctionne correctement, définissez l'étape de lancement sur BETA ou GA.

Maintenance

Les fonctions de tâche et les fonctionnalités de produit sont en constante évolution. Pour que les rôles personnalisés restent à jour et que le principe du moindre privilège soit respecté, des efforts de maintenance sont nécessaires.

Par exemple, lorsqu'un service publié obtient de nouvelles fonctionnalités bêta, ces méthodes d'API deviennent accessibles au public et les autorisations sont automatiquement ajoutées aux rôles de base et prédéfinis correspondants. Vos rôles personnalisés pour ce service n'héritent pas de ces nouvelles autorisations. Par conséquent, les utilisateurs affectés à ces rôles personnalisés pourraient signaler qu'ils ne peuvent pas accéder aux nouvelles fonctionnalités bêta. À ce stade, vous pouvez choisir de les ajouter, ou peut-être de créer un rôle personnalisé distinct pour accorder à certains utilisateurs uniquement l'accès à ces fonctionnalités bêta.

Bien que Google puisse mettre à jour un rôle prédéfini existant en ajoutant (ou en supprimant) des autorisations, nous ne modifions pas les rôles personnalisés en fonction des rôles prédéfinis. Les rôles personnalisés sont des listes plates d'autorisations. Il n'existe pas de lien vers le ou les rôles prédéfinis à partir desquels un rôle personnalisé peut avoir été créé.

Si un rôle personnalisé est basé sur des rôles prédéfinis, nous vous recommandons de les répertorier dans le champ de description du rôle personnalisé. Cela vous permet de vérifier plus facilement si vous devez mettre à jour le rôle personnalisé en fonction des modifications apportées à un rôle prédéfini. Cloud Console place automatiquement ces informations dans la description lors de la création d'un rôle personnalisé. Pour savoir comment mettre à jour la description d'un rôle personnalisé, consultez la page Modifier un rôle personnalisé existant.

Reportez-vous au journal des modifications des autorisations pour connaître les rôles et les autorisations récemment modifiés.

Désactiver des rôles personnalisés

Si vous ne souhaitez plus que les membres de votre entreprise utilisent le rôle, définissez sa propriété role.stage sur DEPRECATED et définissez éventuellement deprecation_message pour suggérer aux utilisateurs les rôles alternatifs à utiliser ou pour leur indiquer où obtenir plus d'information. Vous devez également vous assurer qu'aucune stratégie de votre entreprise ne fait référence au rôle obsolète.

Lorsque vous êtes sûr que le rôle peut être désactivé, appelez roles:UpdateRole() pour désactiver ce rôle.

Limites connues

  • Certains rôles prédéfinis contiennent des autorisations qui ne sont pas autorisées dans les rôles personnalisés. Pour vérifier si vous pouvez utiliser une autorisation spécifique dans un rôle personnalisé, consultez la section Niveau de compatibilité des autorisations dans les rôles personnalisés.
  • L'autorisation resourcemanager.projects.list n'est disponible que pour les rôles personnalisés au niveau de l'organisation et non pour les rôles personnalisés au niveau du projet. Lorsque vous copiez un rôle prédéfini comprenant l'autorisation resourcemanager.projects.list dans un nouveau rôle personnalisé au niveau du projet, l'un des messages suivants s'affiche :
    • Cloud Console : le message d'avertissement suivant s'affiche : "Non applicable aux rôles personnalisés au niveau du projet". L'autorisation resourcemanager.projects.list est automatiquement désélectionnée de la liste des autorisations incluses et vous pouvez continuer à créer le rôle.
    • Outil de ligne de commande gcloud du SDK Cloud : le message d'erreur suivant est renvoyé : INVALID_ARGUMENT: Permission resourcemanager.projects.list is not valid. Le rôle personnalisé ne sera créé qu'une fois l'autorisation resourcemanager.projects.list supprimée de la définition du rôle et qu'une fois que vous aurez réitéré l'opération.
    • API Google Cloud : le message d'erreur suivant est renvoyé : Permission resourcemanager.projects.list is not valid, avec un code d'erreur HTTP 400 et l'état INVALID_ARGUMENT. Le rôle personnalisé ne sera créé qu'une fois l'autorisation resourcemanager.projects.list supprimée de la définition du rôle et qu'une fois que vous aurez réitéré l'opération.

Étapes suivantes

Découvrez comment créer des rôles personnalisés.