Comprendre les rôles personnalisés d'IAM

Cloud Identity and Access Management (Cloud IAM) fournit des rôles prédéfinis qui offrent un accès précis à des ressources spécifiques de Google Cloud et empêchent tout accès non souhaité à d'autres ressources.

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

Cette rubrique ne fournit pas une liste complète de toutes les autorisations Cloud 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 Cloud 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 trois types de rôles dans Cloud IAM : les rôles primitifs, les rôles prédéfinis et les rôles personnalisés.

Les rôles primitifs incluent trois rôles qui existaient avant la mise en place de Cloud 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.

Vous créez un rôle personnalisé en associant une ou plusieurs des autorisations Cloud IAM disponibles. Les autorisations permettent aux utilisateurs d'effectuer des actions spécifiques sur les ressources Google Cloud. Dans le monde Cloud 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 Google 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 de rôle Entreprise

Si une entreprise est associée à votre compte GCP, le rôle Administrateur de rôle Entreprise vous permet de gérer tous les rôles personnalisés de votre entreprise. Vous pouvez uniquement attribuer ce rôle au niveau de l'entreprise. Seuls les administrateurs d'entreprise peuvent attribuer le rôle Administrateur de rôle Entreprise.

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

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 Cloud 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 description peuvent comporter jusqu'à 256 caractères et inclure des caractères alphanumériques, en majuscules et minuscules.

Tester et déployer

Les rôles personnalisés incluent une propriété role.stage. Tout d'abord, définissez l'étape sur ALPHA pour indiquer que le rôle est en tout début de développement et pas encore prêt pour la production. Ensuite, autorisez un ensemble de membres de votre entreprise à utiliser le rôle dans quelques exemples de cas d'utilisation.

Une fois les membres satisfaits du rôle personnalisé créé, définissez la propriété role.stage sur BETA ou GA. En règle générale, si votre rôle personnalisé fait référence à des autorisations pour des services en version bêta, vous devez définir la propriété sur BETA, et non sur GA, à moins que le service ne soit pas en version bêta.

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 primitif et prédéfini 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 de rôle, définissez la propriété role.stage sur DEPRECATED. Vous pouvez également définir deprecation_message pour permettre aux utilisateurs de savoir quels rôles alternatifs devraient être utilisés ou à quel endroit ils peuvent obtenir plus d'informations. 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.