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 ressources Google 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 comprennent les rôles "Propriétaire", "Éditeur" et "Lecteur" qui existaient avant la mise en place d'IAM.
  • 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 :

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 présentent généralement, mais pas toujours, un rapport 1:1 vis-à-vis des 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 existaient avant la mise en place d'IAM. Ils étaient initialement appelés rôles primitifs. Vous pouvez utiliser les rôles de base pour accorder aux comptes principaux un accès étendu aux ressources Google Cloud.

Lorsque vous attribuez un rôle de base à un compte principal, le compte principal obtient toutes les autorisations du rôle de base. Il obtient également toutes les autorisations que les services fournissent aux comptes principaux avec des rôles de base, 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 rôles de base attribuent aux utilisateurs sur tous les services Google Cloud :

Rôles 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, telles que la création d'applications App 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 de propriétaire ne contient pas toutes les autorisations pour toutes les ressources Google Cloud. Par exemple, il ne contient pas les autorisations nécessaires pour modifier vos informations de paiement Cloud Billing ni pour 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

Vous pouvez attribuer des rôles de base à l'aide de la console Google Cloud, l'API et gcloud CLI. Toutefois, pour accorder le rôle Propriétaire sur un projet à un utilisateur externe à votre organisation, vous devez utiliser la console Google Cloud, et non gcloud CLI. Si votre projet ne fait pas partie d'une organisation, vous devez utiliser la console Google Cloud pour attribuer le rôle Propriétaire.

Pour obtenir des instructions, consultez la page 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 Cloud spécifiques. Ces rôles sont créés et gérés par Google. Google met automatiquement à jour ses autorisations si nécessaire, par exemple lorsque Google 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 la section Choisir des rôles prédéfinis.

Pour obtenir la liste complète 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 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.

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.

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 ressources Google 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.

Quand utiliser les rôles personnalisés

Dans la plupart des cas, vous devez pouvoir utiliser des rôles prédéfinis au lieu des rôles personnalisés. Les rôles prédéfinis sont gérés par Google et sont mis à jour automatiquement lorsque de nouvelles autorisations, de nouvelles fonctionnalités ou de nouveaux services sont ajoutés à Google Cloud. En revanche, Google ne gère pas les rôles personnalisés. Lorsque Google Cloud ajoute de nouvelles autorisations, de nouvelles fonctionnalités ou de nouveaux services, vos rôles personnalisés ne sont pas mis à jour automatiquement.

Toutefois, vous pouvez avoir besoin 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é.

Tenez également compte des limites suivantes :

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

  • Le nombre de rôles personnalisés que vous pouvez créer est limité :

    • Vous pouvez créer jusqu'à 300 rôles personnalisés au niveau de l'organisation dans votre organisation.
    • Vous pouvez créer jusqu'à 300 rôles personnalisés au niveau du projet dans chaque projet de votre organisation.

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 console Google 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és Google 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