Comprendre les rôles personnalisés d'IAM

Identity and Access Management (IAM) fournit des rôles prédéfinis qui accordent des accès précis à des ressources Google Cloud spécifiques et permettent d'empêcher tout accès indésirable à d'autres ressources.

IAM vous permet également de créer des rôles IAM personnalisés. Les rôles personnalisés vous aident à appliquer le principe du moindre privilège, car ils permettent de s'assurer que les comptes principaux de votre organisation disposent uniquement des autorisations nécessaires.

Envisagez de créer un rôle personnalisé dans les situations suivantes :

  • Un compte principal a besoin d'une autorisation, mais chaque rôle prédéfini qui inclut cette autorisation inclut également des autorisations dont le compte principal n'a pas besoin et dont il ne devrait pas disposer.
  • Vous utilisez des recommandations de rôles pour remplacer les attributions de rôles trop permissives par des attributions de rôles plus appropriées. Dans certains cas, il est possible que vous receviez une recommandation de créer un rôle personnalisé.

Certaines autorisations IAM ne sont pas compatibles avec les rôles personnalisés. Pour vérifier si une autorisation spécifique est compatible, 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 les autorisations. Vous attribuez plutôt des rôles contenant 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. Google met automatiquement à jour leurs autorisations si nécessaire, par exemple lorsque Google Cloud ajoute de nouvelles fonctionnalités ou de nouveaux services.

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. Lorsque vous ajoutez une autorisation à un rôle personnalisé, vous devez spécifier explicitement le service, la ressource et le verbe. Vous ne pouvez pas utiliser de caractères génériques (*).

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.

Lorsque vous créez un rôle personnalisé au niveau du projet, celui-ci ne peut pas contenir d'autorisations qui ne sont disponibles qu'au niveau du dossier ou de l'organisation. Par exemple, vous ne pouvez pas utiliser l'autorisation resourcemanager.organizations.get dans un rôle personnalisé au niveau du projet, car un projet ne peut pas contenir d'autres projets. Par conséquent, l'autorisation n'est utile qu'au niveau du dossier ou de l'organisation.

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 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

Vous pouvez inclure de nombreuses autorisations IAM, mais pas toutes. Chaque autorisation est associée à l'un des niveaux de compatibilité suivants dans les rôles personnalisés :

Niveau de compatibilité Description
SUPPORTED L'autorisation est entièrement compatible dans les rôles personnalisés.
TESTING Google teste l'autorisation de vérifier sa compatibilité avec les rôles personnalisés. Vous pouvez inclure l'autorisation dans des rôles personnalisés, mais cela est susceptible d'entraîner un comportement inattendu. L'utilisation en production est déconseillée.
NOT_SUPPORTED L'autorisation n'est pas compatible dans les rôles personnalisés.

Certaines autorisations peuvent ne pas s'afficher ou être utilisées dans un rôle personnalisé, même si elles sont compatibles avec les rôles personnalisés. Par exemple, une autorisation peut ne pas être disponible pour des rôles personnalisés si vous n'avez pas activé l'API pour le service. De plus, si vous créez un rôle personnalisé au niveau du projet, vous ne pouvez pas utiliser les autorisations au niveau de l'organisation.

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 d'autorisation, vous devez utiliser le modèle lecture-modification-écriture. Par conséquent, pour mettre à jour une stratégie d'autorisation, 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 la console Google Cloud.

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 44 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, la console Google Cloud 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. Les étapes de lancement les plus courantes pour les rôles personnalisés actifs sont ALPHA, BETA et GA. Ces étapes de lancement sont informatives ; elles vous aident à savoir si chaque rôle est prêt à être utilisé à grande échelle. DISABLED est une autre étape de lancement courante. Cette étape de lancement vous permet de désactiver un rôle personnalisé.

Nous vous recommandons d'utiliser les étapes de lancement ALPHA, BETA et GA pour transmettre les informations suivantes sur le rôle :

  • 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.

Pour obtenir la liste complète des étapes de lancement possibles, consultez la documentation de référence sur les rôles.

Pour savoir comment modifier l'étape de lancement d'un rôle, consultez la section Modifier un rôle personnalisé existant.

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. La console Google Cloud place automatiquement ces informations dans la description lors de la création d'un rôle personnalisé.

Pour apprendre à mettre à jour les autorisations et la description d'un rôle personnalisé, consultez la section 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 les rôles personnalisés

Si vous ne souhaitez plus que les membres de votre organisation utilisent un rôle personnalisé, vous pouvez le désactiver. Pour désactiver le rôle, définissez son étape de lancement sur DISABLED.

Lorsqu'un rôle est désactivé, toutes les liaisons de rôle qui attribuent le rôle sont désactivées, ce qui signifie que l'attribution du rôle à un utilisateur n'a aucun effet.

Pour apprendre à désactiver un rôle personnalisé, consultez la section Désactiver un rôle personnalisé.

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.
  • Les rôles personnalisés peuvent contenir jusqu'à 3 000 autorisations. En outre, la taille totale maximale du titre, de la description et des noms d'autorisations pour un rôle personnalisé est de 64 ko.
  • 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 :
    • La console Google Cloud : 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.
    • CLI gcloud Google Cloud CLI : 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.

Étape suivante

  • Découvrez comment créer des rôles personnalisés.
  • Appliquez davantage le principe du moindre privilège avec des recommandations de rôles, ce qui vous permet de réduire le champ d'application des autorisations de vos comptes principaux en toute sécurité.