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 membres authentifiés. Une stratégie IAM définit et applique les rôles attribués aux membres, et cette stratégie 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.

Architecture IAM

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

  • Membre. Un membre peut être un compte Google (pour les utilisateurs finaux), un compte de service (pour les applications et les machines virtuelles), un groupe Google, ou un domaine Google Workspace ou Cloud Identity pouvant accéder à une ressource. L'identité d'un membre correspond à 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é à des domaines Google Workspace ou 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 membre, vous lui accordez toutes les autorisations contenues dans ce rôle.
  • Stratégie. La stratégie IAM associe un ou plusieurs membres à un rôle. Lorsque vous souhaitez définir qui (membre) 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 membres, par exemple userid@gmail.com, à des rôles tel que celui d'"Administrateur App Engine" (roles/appengine.appAdmin). Si la stratégie est associée à un projet, les membres 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 membres. Les membres peuvent être de plusieurs types :

  • Compte Google
  • Compte de service
  • Groupe Google
  • Domaine Google Workspace
  • Domaine Cloud Identity

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 qui appartient à une application 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 membres à 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.

Domaine Google Workspace

Un domaine Google Workspace représente un groupe virtuel de tous les comptes Google créés dans le compte Google Workspace d'une organisation. Les domaines Google Workspace représentent le nom de domaine Internet de votre organisation (par exemple, example.com). Lorsque vous ajoutez un utilisateur à votre domaine Google Workspace, un nouveau compte Google est créé pour l'utilisateur au sein de ce groupe virtuel (par exemple, username@example.com).

Comme les groupes Google, les domaines 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 ressemble à 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.

allAuthenticatedUsers

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 domaine Google Workspace ou Cloud Identity, tels que des comptes personnels Gmail. Les utilisateurs non authentifiés, tels que les visiteurs anonymes, ne sont pas pris en compte.

allUsers

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.

Lorsqu'un membre 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 savoir comment accorder un rôle à un utilisateur, consultez la section Accorder, modifier et révoquer les accès. Pour en savoir plus sur les rôles prédéfinis IAM disponibles, consultez la page Comprendre les rôles. Pour en savoir plus sur les rôles personnalisés, consultez les pages Comprendre les rôles personnalisés d'IAM et Créer et gérer les rôles personnalisés.

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. Une liaison (Binding) associe une liste de membres (members) à un rôle (role).

  • role : le rôle que vous souhaitez attribuer au membre. 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'une ou plusieurs identités, comme décrit dans la section Concepts liés à l'identité de ce document. Chaque type de membre est identifié par un préfixe, tel qu'un compte Google (user:), un compte de service (serviceAccount:), un groupe Google (group:), ou un domaine Google Workspace ou Cloud Identity (domain:). Dans l'exemple d'extrait de code suivant, le rôle storage.objectAdmin est attribué aux membres 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.

Étapes suivantes