Présentation d'IAM

Cette page décrit le fonctionnement du système IAM (gestion de l'authentification et des accès) de Google Cloud et explique comment l'utiliser pour gérer les accès dans Google Cloud.

IAM vous permet d'accorder un accès précis à des ressources spécifiques dans Google Cloud et empêche l'accès à d'autres ressources. IAM vous permet d'appliquer le principe de sécurité du moindre privilège, qui stipule que personne ne devrait avoir plus d'autorisations que nécessaire.

Fonctionnement de Cloud IAM

Avec Cloud IAM, vous gérez le contrôle des accès en définissant qui (identité) dispose de quel type d'accès (rôle) pour quelle ressource. Par exemple, les instances de machine virtuelle Compute Engine, les clusters Google Kubernetes Engine (GKE) et les buckets Cloud Storage sont des ressources Google Cloud. Les organisations, les dossiers et les projets que vous utilisez pour organiser vos ressources sont également des ressources.

Dans Cloud IAM, l'autorisation d'accéder à une ressource n'est pas accordée directement à l'utilisateur final. À la place, les autorisations sont regroupées dans des rôles, et les rôles sont attribués aux comptes principaux authentifiés. (Par le passé, les comptes principaux étaient souvent appelés membres. Certaines API utilisent toujours ce terme.)

Une stratégie d'autorisation, également appelée stratégie IAM, définit et applique les rôles attribués aux comptes principaux. Chaque règle d'autorisation est associée à une ressource. Lorsqu'un membre authentifié tente d'accéder à une ressource, Cloud IAM vérifie la stratégie de la ressource pour déterminer si l'action est autorisée.

Le schéma suivant illustre la gestion des autorisations dans IAM.

Une stratégie d'autorisation avec deux liaisons de rôle. Les liaisons de rôles associent des membres spécifiques à des rôles spécifiques.

Ce modèle de gestion des accès comporte trois parties principales :

  • Compte principal. Un compte principal peut être un compte Google (pour les utilisateurs finaux), un compte de service (pour les applications et les charges de travail de calcul), un groupe Google, un compte Google Workspace ou un domaine Cloud Identity pouvant accéder à une ressource. Chaque compte principal possède son propre identifiant, qui est généralement une adresse e-mail.
  • Rôle. Un rôle est un ensemble d'autorisations. Les autorisations déterminent les opérations autorisées sur une ressource. Lorsque vous attribuez un rôle à un compte principal, vous lui accordez toutes les autorisations contenues dans ce rôle.
  • Stratégie. La stratégie d'autorisation est un ensemble de liaisons de rôles qui associent un ou plusieurs comptes principaux à des rôles individuels. Lorsque vous souhaitez définir qui (compte principal) possède quel type d'accès (rôle) à une ressource, vous devez créer une stratégie d'autorisation et l'associer à la ressource.

Par exemple, dans le schéma précédent, la stratégie d'autorisation associe les comptes principaux, par exemple user@example.com, à des rôles tels que celui d'"Administrateur App Engine" (roles/appengine.appAdmin). Si la stratégie d'autorisation est associée à un projet, les comptes principaux obtiennent les rôles spécifiés au sein de ce projet.

Ces concepts sont décrits plus en détail dans la suite de cette page.

Dans Cloud IAM, vous accordez l'accès aux comptes principaux. Les comptes principaux peuvent être de plusieurs types :

  • Compte Google
  • Compte de service
  • Groupe Google
  • Un compte Google Workspace
  • Domaine Cloud Identity
  • Tous les utilisateurs authentifiés
  • Tous les utilisateurs

Compte Google

Un compte Google représente un développeur, un administrateur ou toute autre personne qui interagit avec Google Cloud. Toute adresse e-mail associée à un compte Google peut être une identité, y compris les adresses gmail.com ou d'autres domaines. Les nouveaux utilisateurs peuvent créer un compte Google sur la page de création d'un compte Google.

Compte de service

Un compte de service est un compte destiné à une application ou à une charge de travail de calcul plutôt qu'à un utilisateur final individuel. Lorsque vous exécutez du code hébergé sur Google Cloud, vous spécifiez le compte sous lequel le code doit être exécuté. Vous pouvez créer autant de comptes de service que nécessaire pour représenter les différents composants logiques de votre application. Pour en savoir plus sur l'utilisation d'un compte de service pour authentifier votre application, consultez la page Comptes de service.

Groupe Google

Un groupe Google est une collection nommée de comptes Google et de comptes de service. Chaque groupe Google possède une adresse e-mail unique qui lui est associée. Vous pouvez trouver l'adresse e-mail associée à un groupe Google en accédant à sa page d'accueil, puis en cliquant sur À propos de. Pour en savoir plus sur les groupes Google, consultez la page d'accueil correspondante.

Les groupes Google constituent un moyen pratique d'appliquer des contrôles d'accès à un ensemble d'utilisateurs. Vous pouvez accorder et modifier les accès pour tout un groupe à la fois, plutôt que d'effectuer cette action pour chaque compte de service ou utilisateur. Vous pouvez aussi ajouter des comptes principaux à un groupe Google et en supprimer facilement. Il n'est pas nécessaire de mettre à jour une stratégie d'autorisation pour ajouter ou supprimer des utilisateurs.

Les groupes Google ne disposent pas d'identifiants de connexion et vous ne pouvez pas utiliser ces groupes pour établir une identité afin de demander l'accès à une ressource.

Un compte Google Workspace

Un compte Google Workspace représente un groupe virtuel de tous les comptes Google qu'il contient. Les comptes Google Workspace sont associés au nom de domaine Internet de votre organisation, lequel se présente sous la forme example.com. Lorsque vous créez un compte Google pour un nouvel utilisateur, tel que username@example.com, ce compte Google est ajouté au groupe virtuel dépendant de votre compte Google Workspace.

Comme les groupes Google, les comptes Google Workspace ne peuvent pas être utilisés pour établir une identité, mais ils permettent une gestion pratique des autorisations.

Domaine Cloud Identity

Un domaine Cloud Identity est semblable à un domaine Google Workspace, car il représente un groupe virtuel de tous les comptes Google d'une entreprise. Toutefois, les utilisateurs de domaines Cloud Identity n'ont pas accès aux applications et aux fonctionnalités de Google Workspace. Pour en savoir plus, consultez la section À propos de Cloud Identity.

Tous les utilisateurs authentifiés

La valeur allAuthenticatedUsers est un identifiant spécial qui représente tous les comptes de service et tous les internautes qui se sont authentifiés avec un compte Google. Cet identifiant inclut les comptes qui ne sont pas associés à un compte Google Workspace ou à un domaine Cloud Identity, tels que des comptes personnels Gmail. Les utilisateurs non authentifiés, tels que les visiteurs anonymes, ne sont pas pris en compte.

Ce type d'entité principale n'inclut pas les identités qui proviennent de fournisseurs d'identité (IdP) externes. Si vous utilisez la fédération d'identité de personnel ou la fédération d'identité de charge de travail, n'utilisez pas allAuthenticatedUsers. Optez plutôt pour l'une des solutions suivantes :

Certains types de ressources ne sont pas compatibles avec ce type de compte principal.

Tous les utilisateurs

La valeur allUsers est un identifiant spécial qui représente toute personne ayant accès à Internet, y compris les utilisateurs authentifiés et non authentifiés.

Certains types de ressources ne sont pas compatibles avec ce type de compte principal.

Lorsqu'un compte principal authentifié tente d'accéder à une ressource, Cloud IAM vérifie la stratégie d'autorisation de la ressource pour déterminer si l'action est autorisée.

Cette section décrit les entités et les concepts impliqués dans le processus d'autorisation.

Ressource

Si un utilisateur a besoin d'accéder à une ressource Google Cloud spécifique, vous pouvez lui accorder un rôle pour cette ressource. Les projets, les instances Compute Engine et les buckets Cloud Storage sont des exemples de ressources.

Certains services accordent les autorisations Cloud IAM avec davantage de précision qu'au niveau d'un projet. Par exemple, vous pouvez attribuer le rôle Administrateur de l'espace de stockage (roles/storage.admin) à un utilisateur sur un bucket Cloud Storage spécifique, ou attribuer le rôle Administrateur d'instances Compute (roles/compute.instanceAdmin) à un utilisateur sur une instance Compute Engine spécifique.

Vous pouvez également accorder des autorisations Cloud IAM au niveau d'un projet. Les autorisations sont ensuite héritées par toutes les ressources du projet. Par exemple, pour accorder l'accès à tous les buckets Cloud Storage d'un projet, vous devez accorder l'accès au projet plutôt qu'à chaque bucket de manière individuelle. De même, pour accorder l'accès à toutes les instances Compute Engine d'un projet, vous devez accorder l'accès au projet plutôt qu'à chaque instance de manière individuelle.

Pour en savoir plus sur l'attribution des rôles en fonction des ressources, consultez la page Comprendre les rôles, puis reportez-vous à la colonne Ressource la plus basse pour vous renseigner sur un rôle donné.

Autorisations

Les autorisations déterminent les opérations autorisées sur une ressource. Dans le monde de Cloud IAM, les autorisations sont représentées sous la forme suivante : service.resource.verb (par exemple, pubsub.subscriptions.consume).

Les autorisations correspondent souvent les unes aux autres avec les méthodes de l'API REST. Autrement dit, chaque service Google Cloud compte un ensemble d'autorisations associées à chaque méthode de l'API REST dont il dispose. Ces autorisations sont nécessaires à l'appelant de la méthode. Par exemple, si vous utilisez Pub/Sub et que vous devez appeler la méthode topics.publish(), vous devez disposer de l'autorisation pubsub.topics.publish pour ce sujet.

Vous n'accordez pas d'autorisations directement aux utilisateurs. À la place, vous identifiez les rôles qui contiennent les autorisations appropriées, puis vous accordez les rôles aux utilisateurs. Pour obtenir la liste de toutes les autorisations disponibles et des rôles qui les contiennent, consultez la documentation de référence sur les autorisations.

Rôle

Un rôle est un ensemble d'autorisations. Vous ne pouvez pas accorder directement une autorisation à l'utilisateur. À la place, vous lui accordez un rôle. Lorsque vous attribuez un rôle à un utilisateur, vous lui accordez toutes les autorisations que compte le rôle.

Autorisation de mappage de rôles

Il existe plusieurs types de rôles dans IAM :

  • Les rôles de base : ces rôles sont toujours disponibles dans Google Cloud Console. Il s'agit des rôles Propriétaire, Éditeur et Lecteur.

  • Les rôles prédéfinis : ces rôles permettent un contrôle d'accès plus précis que les rôles de base. Par exemple, le rôle prédéfini Éditeur Pub/Sub (roles/pubsub.publisher) permet uniquement de publier des messages dans un sujet Pub/Sub.

  • Les rôles personnalisés : il s'agit de rôles que vous créez pour adapter les autorisations aux besoins de votre organisation lorsque les rôles prédéfinis ne répondent pas à vos besoins.

Pour en savoir plus sur les rôles, consultez les ressources suivantes :

Stratégie d'autorisation

Vous pouvez attribuer des rôles aux utilisateurs en créant une stratégie d'autorisation, qui est un ensemble d'instructions qui définissent qui a quel type d'accès. Une stratégie d'autorisation est associée à une ressource et permet d'en contrôler tous les accès.

Stratégie IAM

Une stratégie d'autorisation se compose d'une liste de liaisons de rôles. Une liaison de rôle associe une liste de comptes principaux à un rôle.

  • role : le rôle que vous souhaitez attribuer au compte principal. role est spécifié au format suivant : roles/service.roleName. Par exemple, Cloud Storage fournit les rôles roles/storage.objectAdmin, roles/storage.objectCreator et roles/storage.objectViewer, entre autres.

  • members : une liste d'un ou plusieurs comptes principaux, comme décrit dans la section Concepts liés à l'identité de ce document. Chaque type de compte principal est identifié par un préfixe, tel qu'un compte Google (user:), un compte de service (serviceAccount:), un groupe Google (group:), un compte Google Workspace ou un domaine Cloud Identity (domain:). Dans l'exemple d'extrait de code suivant, le rôle storage.objectAdmin est attribué aux comptes principaux suivants avec le préfixe approprié : user:ali@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com, group:admins@example.com, et domain:google.com. Le rôle objectViewer est attribué à user:maria@example.com.

L'extrait de code suivant montre la structure d'une stratégie d'autorisation.

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "user:ali@example.com",
        "serviceAccount:my-other-app@appspot.gserviceaccount.com",
        "group:admins@example.com",
        "domain:google.com"
      ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:maria@example.com"
      ]
    }
  ]
}

Cloud IAM et les API de stratégie

Cloud IAM fournit un ensemble de méthodes que vous pouvez utiliser pour créer et gérer des stratégies d'autorisation sur des ressources Google Cloud. Ces méthodes sont exposées par les services compatibles avec IAM. Par exemple, les méthodes IAM sont exposées par les API Resource Manager, Pub/Sub et Cloud Life Sciences, pour n'en nommer que quelques-unes.

Les méthodes IAM sont les suivantes :

  • setIamPolicy() : définit des stratégies d'autorisation pour vos ressources.
  • getIamPolicy() : récupère une stratégie d'autorisation précédemment définie.
  • testIamPermissions() : teste si l'appelant dispose des autorisations spécifiées pour une ressource.

Vous trouverez les rubriques de référence des API pour ces méthodes dans la documentation de chaque service compatible avec IAM.

Hiérarchie des ressources

Les ressources Google Cloud sont organisées de façon hiérarchique :

  • L'organisation constitue le nœud racine de la hiérarchie.
  • Les dossiers représentent les enfants de l'organisation ou d'un autre dossier.
  • Les projets représentent les enfants de l'organisation ou d'un dossier.
  • Les ressources pour chaque service sont les enfants des projets.

Chaque ressource a un seul parent. Consultez la rubrique Hiérarchie des ressources Resource Manager pour en savoir plus.

Le schéma suivant montre un exemple de hiérarchie de ressources Google Cloud.

Hiérarchie des ressources IAM

Vous pouvez définir une stratégie IAM à n'importe quel niveau de la hiérarchie des ressources : au niveau de l'entreprise, du dossier, du projet ou de la ressource. Les ressources héritent des stratégies de toutes leurs ressources parentes. La stratégie d'autorisation effective d'une ressource combine la stratégie d'autorisation définie pour cette ressource et la stratégie d'autorisation héritée des niveaux supérieurs de la hiérarchie.

Cet héritage des stratégies est transitif. En d'autres termes, les ressources héritent des stratégies d'autorisation du projet, lequel hérite des stratégies d'autorisation des dossiers, lesquels héritent des stratégies d'autorisation de l'organisation. Par conséquent, les stratégies d'autorisation au niveau d'une organisation s'appliquent également au niveau des ressources.

Par exemple, dans le diagramme précédent, topic_a est une ressource Pub/Sub qui réside dans le projet example-prod. Si vous attribuez le rôle Éditeur à micah@example.com pour example-prod et le rôle Rédacteur à song@example.com pour topic_a, micah@example.com reçoit en réalité le rôle Éditeur et song@example.com reçoit en réalité le rôle Rédacteur pour topic_a.

Les stratégies d'autorisation des ressources enfants héritent des stratégies d'autorisation de leurs ressources parentes. Par exemple, si vous accordez à un même utilisateur le rôle Éditeur pour un projet et le rôle Lecteur pour une ressource enfant, l'utilisateur dispose toujours du rôle Éditeur pour la ressource enfant. Si vous modifiez la hiérarchie des ressources, l'héritage des stratégies est également modifié. Par exemple, si vous déplacez un projet dans une organisation, il hérite de la stratégie d'autorisation de l'organisation.

Compatibilité de Cloud IAM avec les services Google Cloud

Avec IAM, toutes les méthodes d'API des services Google Cloud sont contrôlées, l'objectif étant de vérifier que le compte à l'origine de la requête API dispose de l'autorisation appropriée pour utiliser la ressource.

Les services Google Cloud proposent des rôles prédéfinis permettant un contrôle d'accès précis. Par exemple, Compute Engine propose les rôles Administrateur d'instances Compute et Administrateur de réseaux Compute, et App Engine propose les rôles Administrateur App Engine et Administrateur de services App Engine.

Les rôles prédéfinis sont disponibles pour la plupart des services Google Cloud. Pour en savoir plus, consultez la liste de tous les rôles prédéfinis. Si vous souhaitez contrôler encore davantage les autorisations, vous pouvez envisager de créer un rôle personnalisé.

Vous pouvez attribuer, avec davantage de précision qu'au niveau d'un projet, certains rôles aux utilisateurs pour qu'ils puissent accéder aux ressources. Par exemple, vous pouvez créer une stratégie d'autorisation qui attribue à un utilisateur le rôle d'abonné pour un sujet Pub/Sub spécifique. La liste de tous les rôles prédéfinis indique le type de ressource au niveau le plus bas ou le type de ressource le plus précis acceptant chaque rôle.

Modèle de cohérence pour l'API IAM

L'API IAM est cohérente à terme. En d'autres termes, si vous écrivez des données avec l'API IAM, puis que vous les lisez immédiatement, l'opération de lecture peut renvoyer une ancienne version des données. En outre, les modifications que vous apportez peuvent prendre un certain temps pour affecter les contrôles d'accès.

Ce modèle de cohérence affecte le fonctionnement de l'API IAM. Par exemple, si vous créez un compte de service, puis que vous faites immédiatement référence à ce compte de service dans une autre requête, l'API IAM peut dire que le compte de service est introuvable. Ce comportement est dû au fait que les opérations sont cohérentes à terme. Il peut s'écouler un certain temps avant que le nouveau compte de service ne devienne visible par les requêtes de lecture.

Étape suivante

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Essai gratuit