Rôles et autorisations

Cette page décrit les rôles IAM (Identity and Access Management), qui sont des ensembles d'autorisations IAM.

Un rôle contient un ensemble d'autorisations qui vous permet d'effectuer des actions spécifiques sur les ressourcesGoogle Cloud . Pour mettre les autorisations à la disposition des comptes principaux, y compris les utilisateurs, les groupes et les comptes de service, vous attribuez des rôles aux comptes principaux.

Avant de commencer

Types de rôles

Il existe trois types de rôles dans IAM :

  • Les rôles de base, qui offrent un accès étendu aux ressources Google Cloud .
  • Les rôles prédéfinis, qui fournissent un accès précis à un service spécifique et sont gérés par Google Cloud.
  • Les rôles personnalisés qui fournissent un accès précis en fonction d'une liste d'autorisations spécifiée par l'utilisateur.

Pour déterminer si une autorisation est incluse dans un rôle de base, prédéfini ou personnalisé, vous pouvez employer l'une des méthodes suivantes :

Pour savoir quand utiliser des types de rôles spécifiques, consultez Choisir le type de rôle à utiliser.

Composants des rôles

Chaque rôle comporte les composants suivants :

  • Titre : nom lisible du rôle. Le titre du rôle permet d'identifier le rôle dans la console Google Cloud .

  • Nom : identifiant du rôle dans l'un des formats suivants :

    • Rôles prédéfinis : roles/SERVICE.IDENTIFIER
    • Rôles personnalisés au niveau du projet : projects/PROJECT_ID/roles/IDENTIFIER
    • Rôles personnalisés au niveau de l'organisation : organizations/ORG_ID/roles/IDENTIFIER

    Le nom du rôle permet d'identifier le rôle dans les stratégies d'autorisation.

  • ID : identifiant unique du rôle. Pour les rôles de base et les rôles prédéfinis, l'ID est identique au nom du rôle. Pour les rôles personnalisés, l'ID correspond à tout ce qui suit roles/ dans le nom du rôle.

  • Description : description lisible du rôle.

  • Étape : étape du rôle dans le cycle de lancement, par exemple ALPHA, BETA ou GA. Pour en savoir plus sur les étapes de lancement, consultez la page Tester et déployer.

  • Autorisations : autorisations incluses dans le rôle. Les autorisations permettent aux comptes principaux de réaliser des opérations spécifiques sur les ressources Google Cloud . Lorsque vous attribuez un rôle à un compte principal, le compte principal obtient toutes les autorisations du rôle.

    Les autorisations sont au format suivant :

    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 sont généralement, mais pas toujours, mappées sur les 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 doit disposer de l'autorisation associée. Par exemple, pour appeler la méthode projects.topics.publish de l'API Pub/Sub, vous devez disposer de l'autorisation pubsub.topics.publish.

  • ETag : identifiant de la version du rôle permettant d'empêcher les mises à jour simultanées de s'écraser mutuellement. Les rôles de base et les rôles prédéfinis possèdent toujours l'ETag AA==. Les ETags des rôles personnalisés changent à chaque modification des rôles.

Rôles de base

Les rôles de base sont des rôles très permissifs qui donnent un accès étendu aux ressourcesGoogle Cloud .

Les rôles de base dans IAM sont Administrateur (roles/admin), Rédacteur (roles/writer) et Lecteur (roles/reader). IAM propose également trois rôles de base anciens qui existaient avant l'introduction d'IAM : Propriétaire (roles/owner), Éditeur (roles/editor) et Lecteur (roles/viewer). Pour en savoir plus sur ces rôles, consultez Rôles de base anciens sur cette page.

Le tableau suivant récapitule les autorisations que les rôles Administrateur, Lecteur et Rédacteur accordent aux principaux sur tous les services Google Cloud  :

Rôle de base Autorisations
Lecteur (roles/reader)

Autorisations permettant de réaliser des actions en lecture seule qui n'affectent pas l'état du projet, comme consulter (mais pas modifier) des ressources ou des données existantes.

Pour obtenir la liste des autorisations du rôle Lecteur, consultez les détails du rôle dans la console Google Cloud  :

Accéder au rôle Lecteur

Rédacteur (roles/writer)

Toutes les autorisations du rôle Lecteur et les autorisations permettant de réaliser des actions qui modifient l'état du projet, comme modifier des ressources existantes.

Les autorisations du rôle Lecteur vous permettent de créer et de supprimer des ressources pour la plupart des services Google Cloud . Toutefois, le rôle "Rédacteur" ne contient pas les autorisations permettant d'effectuer toutes les actions pour tous les services. Pour savoir comment vérifier si un rôle dispose des autorisations dont vous avez besoin, consultez la section Types de rôles sur cette page.

Pour obtenir la liste des autorisations du rôle Rédacteur, consultez les détails du rôle dans la console Google Cloud  :

Accéder au rôle Rédacteur

Administrateur (roles/admin)

Toutes les autorisations du rôle Lecteur, plus les autorisations permettant de réaliser des actions telles que les suivantes :

  • Effectuer des tâches sensibles, comme gérer les liaisons de tags pour les ressources Compute Engine
  • Gérer les rôles et autorisations d'un projet et de toutes ses ressources
  • Configurer la facturation pour un projet

Le rôle Administrateur ne contient pas toutes les autorisations pour toutes les ressources Google Cloud . Par exemple, il ne contient pas les autorisations permettant de modifier vos informations de paiement Cloud Billing ni de créer des règles de refus IAM.

Pour obtenir la liste des autorisations du rôle Administrateur, consultez les détails du rôle dans la console Google Cloud  :

Accéder au rôle Administrateur

Vous ne pouvez pas utiliser la console Google Cloud pour attribuer les rôles Lecteur, Rédacteur ou Administrateur. Utilisez plutôt l'API ou gcloud CLI. Vous pouvez également créer des droits d'accès pour ces rôles à l'aide de Privileged Access Manager.

Pour obtenir des instructions, consultez la page Accorder, modifier et révoquer les accès.

Anciens rôles de base

Les anciens rôles de base existaient avant l'introduction d'IAM. Ils étaient initialement appelés rôles primitifs. Contrairement aux autres rôles de base, vous ne pouvez pas ajouter de conditions aux liaisons de rôles pour les anciens rôles de base.

Les anciens rôles de base sont Propriétaire (roles/owner), Éditeur (roles/editor) et Lecteur (roles/viewer).

Lorsque vous attribuez un ancien rôle de base à un compte principal, le compte principal obtient toutes les autorisations du rôle. Le compte principal obtient également toutes les autorisations que les services fournissent aux comptes principaux avec des rôles de base hérités, par exemple les autorisations obtenues via les valeurs d'usage de Cloud Storage et l'appartenance à un groupe spécial BigQuery.

Le tableau suivant récapitule les autorisations que les anciens rôles de base accordent aux principaux sur tous les services Google Cloud  :

Ancien rôle de base Autorisations
Lecteur (roles/viewer)

Autorisations permettant de réaliser des actions en lecture seule qui n'affectent pas l'état du projet, comme consulter (mais pas modifier) des ressources ou des données existantes.

Pour obtenir la liste des autorisations du rôle Lecteur, consultez les détails du rôle dans la console Google Cloud  :

Accéder au rôle Lecteur

Éditeur (roles/editor)

Toutes les autorisations accordées au rôle de lecteur et autorisations permettant de réaliser des actions qui modifient l'état du projet, comme modifier des ressources existantes.

Les autorisations du rôle Éditeur vous permettent de créer et de supprimer des ressources pour la plupart des services Google Cloud . Toutefois, le rôle "Éditeur" ne contient pas les autorisations permettant d'effectuer toutes les actions pour tous les services. Pour savoir comment vérifier si un rôle dispose des autorisations dont vous avez besoin, consultez la section Types de rôles sur cette page.

Pour obtenir la liste des autorisations du rôle Éditeur, consultez les détails du rôle dans la console Google Cloud  :

Accéder au rôle Éditeur

Propriétaire (roles/owner)

Toutes les autorisations accordées au rôle d'éditeur, plus les autorisations permettant de réaliser des actions telles que les suivantes :

  • Effectuer des tâches sensibles, comme gérer les liaisons de tags pour les ressources Compute Engine
  • Gérer les rôles et autorisations d'un projet et de toutes ses ressources
  • Configurer la facturation pour un projet

Le rôle Propriétaire ne contient pas toutes les autorisations pour toutes les ressources Google Cloud . Par exemple, il ne contient pas les autorisations permettant de modifier vos informations de paiement Cloud Billing ni de créer des règles de refus IAM.

Pour obtenir la liste des autorisations du rôle Propriétaire, consultez les détails du rôle dans la console Google Cloud  :

Accéder au rôle Propriétaire

En général, vous pouvez attribuer des rôles de base anciens à l'aide de la console Google Cloud , de l'API ou de gcloud CLI. Toutefois, vous devez utiliser la consoleGoogle Cloud pour attribuer le rôle Propriétaire dans les cas suivants :

  • L'utilisateur auquel vous attribuez le rôle de propriétaire ne fait pas partie de votre organisation.
  • Le projet pour lequel vous accordez le rôle de propriétaire ne fait partie d'aucune organisation.

De plus, vous ne pouvez attribuer le rôle de propriétaire qu'aux types de comptes principaux suivants :

  • Comptes Google
  • Comptes de service dans votre organisation
  • Groupes Google de votre organisation

Pour savoir comment accorder des rôles, consultez Accorder, modifier et révoquer les accès.

Rôles prédéfinis

Outre les rôles de base, IAM fournit des rôles prédéfinis supplémentaires qui accordent un accès précis à des ressources Google Cloudspécifiques. Ces rôles sont créés et gérés par Google. Google met automatiquement à jour ses autorisations si nécessaire, par exemple lorsqueGoogle Cloud ajoute de nouvelles fonctionnalités ou de nouveaux services.

Vous pouvez attribuer plusieurs rôles au même utilisateur, à n'importe quel niveau de la hiérarchie de ressources. Par exemple, celui-ci peut disposer des rôles d'administrateur réseau Compute et de lecteur de journaux sur un projet, ainsi que d'un rôle d'éditeur Pub/Sub pour un sujet Pub/Sub au sein de ce projet. Pour répertorier les autorisations contenues dans un rôle, consultez la section Obtenir les métadonnées du rôle.

Pour obtenir de l'aide sur le choix des rôles prédéfinis les plus appropriés, consultez Trouver les rôles prédéfinis adaptés.

Pour obtenir la liste des rôles prédéfinis, consultez la documentation de référence sur les rôles.

Rôles personnalisés

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.

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. 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 ne pouvez créer que 300 clés par organisation et 300 clés par projet.

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.

Pour créer un rôle personnalisé, vous devez combiner une ou plusieurs autorisations IAM compatibles. Pour savoir comment créer un rôle personnalisé, consultez Créer et gérer des rôles personnalisés.

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

Pour obtenir la liste complète des autorisations compatibles avec les rôles personnalisés, consultez Niveaux de compatibilité des autorisations dans les rôles personnalisés.

Un rôle personnalisé au niveau de l'organisation peut inclure l'une des autorisations IAM compatibles avec les rôles personnalisés. Un rôle personnalisé au niveau du projet peut contenir toute autorisation compatible, à l'exception des autorisations qui ne peuvent être utilisées qu'au niveau de l'organisation ou du dossier.

Vous ne pouvez pas inclure d'autorisations spécifiques à un dossier ou à une organisation dans les rôles au niveau du projet, car elles n'effectuent aucune action au niveau du projet. En effet, les ressources de Google Cloud sont organisées de façon hiérarchique. Les autorisations sont héritées via la hiérarchie des ressources, ce qui signifie qu'elles sont efficaces pour la ressource et tous les descendants de cette ressource. Toutefois, les organisations et les dossiers se trouvent toujours au-dessus des projets dans la hiérarchie des ressourcesGoogle Cloud . Par conséquent, vous ne pouvez jamais utiliser l'autorisation qui vous a été accordée au niveau du projet pour accéder à des dossiers ou des organisations. Ainsi, les autorisations spécifiques à un dossier et à une organisation, par exemple resourcemanager.folders.list, sont inefficaces pour les rôles personnalisés au niveau du projet.

Dépendances d'autorisation

Certaines autorisations ne sont efficaces que si elles sont combinées. Par exemple, pour mettre à jour une stratégie d'autorisation, vous devez la lire avant de pouvoir la modifier et l'écrire. 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 sont conçus pour des tâches spécifiques et contiennent toutes les autorisations dont vous avez besoin pour accomplir ces tâches. L'examen de ces rôles vous permet de voir quelles autorisations sont généralement accordées ensemble. Vous pouvez ensuite utiliser ces informations pour concevoir des rôles personnalisés efficaces.

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.

Cycle de vie des rôles personnalisés

Les sections suivantes décrivent les éléments clés à prendre en compte pour chaque phase du cycle de vie d'un rôle personnalisé. Vous pouvez utiliser ces informations pour savoir comment créer et gérer vos rôles personnalisés.

Création

Lorsque vous créez un rôle personnalisé, choisissez un ID, un titre et une description qui vous aideront à identifier le rôle :

  • ID de rôle : l'ID de rôle est un identifiant unique pour le rôle. Il peut comporter jusqu'à 64 octets et contenir des majuscules, des minuscules, des traits de soulignement et des points. Vous ne pouvez pas réutiliser un ID de rôle dans une organisation ou un projet.

    Vous ne pouvez pas modifier les ID de rôle. Réfléchissez donc bien avant de les choisir. Vous pouvez supprimer un rôle personnalisé, mais vous ne pouvez pas créer un rôle personnalisé avec le même ID dans la même organisation ou le même projet tant que le processus de suppression de 44 jours n'est pas terminé. Pour en savoir plus sur le processus de suppression, consultez la page Supprimer un rôle personnalisé.

  • Titre du rôle : le titre du rôle apparaît dans la liste des rôles dans la consoleGoogle Cloud . Le titre ne doit pas nécessairement être unique, mais nous vous recommandons d'utiliser des titres uniques et descriptifs pour mieux distinguer vos rôles. Pensez également à indiquer dans le titre du rôle s'il a été créé 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 : la description du rôle est un champ facultatif dans lequel vous pouvez fournir des informations supplémentaires sur un rôle. Par exemple, vous pouvez inclure l'objectif du rôle, la date de création ou de modification d'un rôle, ainsi que tous les rôles prédéfinis sur lesquels le rôle personnalisé est basé. Les descriptions peuvent comporter jusqu'à 300 octets et contenir des symboles et des caractères alphanumériques en majuscules et minuscules.

Gardez également à l'esprit les dépendances d'autorisation lors de la création de rôles personnalisés.

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.

Lancement

Les rôles personnalisés incluent une étape de lancement dans les métadonnées du rôle. Les étapes de lancement les plus courantes pour les rôles personnalisés 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 pour transmettre les informations suivantes sur le rôle :

  • EAP ou 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ésGoogle Cloud accessibles à tous.
  • DEPRECATED : le rôle n'est plus utilisé.

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

Maintenance

Vous êtes responsable de la gestion des rôles personnalisés. Cela inclut la mise à jour des rôles à mesure que les responsabilités de vos utilisateurs changent, ainsi que la mise à jour des rôles pour permettre aux utilisateurs d'accéder à de nouvelles fonctionnalités nécessitant des autorisations supplémentaires.

Si vous basez votre rôle personnalisé sur des rôles prédéfinis, nous vous recommandons de vérifier régulièrement ces rôles pour modifier les autorisations. Le suivi de ces modifications peut vous aider à décider quand et comment mettre à jour votre rôle personnalisé. Par exemple, vous remarquerez peut-être qu'un rôle prédéfini a été mis à jour avec des autorisations permettant d'utiliser une nouvelle fonctionnalité bêta, et vous pouvez décider d'ajouter également ces autorisations à votre rôle personnalisé.

Pour faciliter la visualisation des rôles prédéfinis, nous vous recommandons de répertorier tous les rôles prédéfinis sur lesquels votre rôle personnalisé est basé dans le champ de description du rôle personnalisé. La console Google Cloud effectue cette opération automatiquement lorsque vous utilisez la console Google Cloud pour créer un rôle personnalisé basé sur des rôles prédéfinis.

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ésactivation…

Si vous ne souhaitez plus que les comptes principaux 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.

Les rôles désactivés apparaissent toujours dans vos stratégies IAM et peuvent être attribués aux comptes principaux, mais ils n'ont aucun effet.

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

Étapes suivantes

  • Utilisez l'outil Policy Troubleshooter pour comprendre pourquoi un utilisateur est autorisé ou non à accéder à une ressource ou à appeler une API.