Présentation

Cette page décrit les concepts de base de la gestion de l'authentification et des accès (Identity and Access Management, IAM).

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 IAM définit et applique les rôles attribués aux comptes principaux, et cette stratégie est associée à une ressource. Lorsqu'un compte principal 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.

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. L'identité d'un compte principal est une adresse e-mail associée à un utilisateur, un compte de service ou un groupe Google. Il peut également s'agir d'un nom de domaine associé à un compte Google Workspace ou à un domaine Cloud Identity.
  • 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 IAM 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 et l'associer à la ressource.

Par exemple, dans le schéma précédent, la stratégie IAM associe les comptes principaux, par exemple user@example.com, à des rôles tel que celui d'"Administrateur App Engine" (roles/appengine.appAdmin). Si la stratégie 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 dans votre application, consultez la page Premiers pas avec l'authentification.

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 une stratégie 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 IAM 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.

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

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

Stratégie IAM

Une stratégie IAM est représentée par l'objet IAM Policy. Un objet Policy IAM est constitué 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 IAM.

{
  "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 de contrôle d'accès sur des ressources Google Cloud. Ces méthodes sont exposées par les services compatibles avec Cloud 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 pour vos ressources.
  • getIamPolicy() : récupère une stratégie 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.
  • 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 applicable à une ressource combine la stratégie définie pour celle-ci et la stratégie 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 du projet, lequel hérite des stratégies des dossiers, lesquels héritent des stratégies de l'organisation. Par conséquent, les stratégies 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 des ressources enfants héritent des stratégies 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, le projet hérite de la stratégie IAM 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 IAM grâce à laquelle vous attribuez le rôle d'abonné à un utilisateur 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

Lorsque vous lisez des données à partir de l'API IAM, chaque lecture 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. Après un court délai, vous pouvez lire la nouvelle version des données. Ce délai est généralement mesuré en secondes, et non en minutes.

En revanche, l'écriture de données dans l'API IAM est cohérente de manière séquentielle. En d'autres termes, les opérations d'écriture sont toujours traitées dans l'ordre dans lequel elles ont été reçues.

Ces modèles de cohérence affectent 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 se produit car les opérations de lecture sont cohérentes à terme. Il peut s'écouler un certain temps avant que le nouveau compte de service devienne visible.

Pour résoudre ce problème, votre application peut relancer la requête avec un intervalle exponentiel entre les tentatives tronqué.

É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