Présentation d'IAM

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

IAM est un outil permettant de gérer les autorisations précises pourGoogle Cloud. En d'autres termes, il vous permet de contrôler qui peut faire quoi sur quelles ressources.

Accès dans Google Cloud

Chaque action dans Google Cloud nécessite certaines autorisations. Lorsqu'un utilisateur tente d'effectuer une action dans Google Cloud(par exemple, créer une instance de VM ou afficher un ensemble de données), IAM vérifie d'abord s'il dispose des autorisations requises. Si ce n'est pas le cas, IAM l'empêche d'effectuer l'action.

Pour accorder des autorisations à un utilisateur dans IAM, vous devez utiliser les trois composants suivants :

  • Compte principal : identité de la personne ou du système auxquels vous souhaitez accorder des autorisations.
  • Rôle : ensemble d'autorisations que vous souhaitez accorder au compte principal
  • Resource (Ressource) : ressource Google Cloud à laquelle vous souhaitez autoriser l'accès au compte principal.

Pour autoriser le compte principal à accéder à la ressource, vous lui attribuez le rôle sur la ressource. Vous attribuez ces rôles à l'aide d'une stratégie d'autorisation.

Les sections suivantes décrivent ces concepts plus en détail.

Comptes principaux

Dans Google Cloud , vous contrôlez l'accès des comptes principaux. Les comptes principaux représentent une ou plusieurs identités authentifiées auprès de Google Cloud.

Par le passé, les comptes principaux étaient appelés membres. Certaines API utilisent toujours ce terme.

Il existe différents types de comptes principaux dans IAM, mais ils peuvent être divisés en deux grandes catégories :

  • Utilisateurs humains : certains types de principaux IAM représentent des utilisateurs humains. Vous utilisez ces types de comptes principaux pour gérer l'accès de vos employés aux ressourcesGoogle Cloud .

    Les types de comptes principaux qui représentent des utilisateurs humains incluent les comptes Google, les groupes Google et les identités fédérées dans les pools d'identités de personnel.

  • Charges de travail : certains types de comptes principaux IAM représentent des charges de travail. Vous utilisez ces types de comptes principaux lorsque vous gérez l'accès de vos charges de travail aux ressourcesGoogle Cloud .

    Les types d'entités principales qui représentent des charges de travail incluent les comptes de service et les identités fédérées dans un pool d'identités de charge de travail.

Pour en savoir plus sur les comptes principaux, consultez Comptes principaux IAM.

Autorisations et rôles

Les autorisations déterminent les opérations autorisées sur une ressource. Dans IAM, les autorisations sont généralement représentées sous la forme service.resource.verb. Souvent, les autorisations correspondent les unes aux autres avec les méthodes de l'API REST. Par exemple, l'autorisation resourcemanager.projects.list vous permet de lister les projets Resource Manager.

Vous ne pouvez pas accorder directement des autorisations à un compte principal. À la place, vous accordez des autorisations aux comptes principaux en leur attribuant des rôles.

Les rôles sont des ensembles d'autorisations. Lorsque vous attribuez un rôle à un compte principal, vous lui accordez toutes les autorisations de ce rôle.

Il existe trois types de rôles :

  • Rôles prédéfinis : rôles gérés par les services Google Cloud . Ces rôles contiennent les autorisations nécessaires pour effectuer des tâches courantes pour chaque service donné. Par exemple, le rôle Diffuseur Pub/Sub (roles/pubsub.publisher) permet de publier des messages dans un sujet Pub/Sub.

  • Rôles personnalisés : rôles que vous créez et qui ne contiennent que les autorisations que vous spécifiez. Vous contrôlez entièrement les autorisations de ces rôles. Toutefois, ils sont plus difficiles à gérer que les rôles prédéfinis. De plus, le nombre de rôles personnalisés que vous pouvez avoir dans votre projet et votre organisation est limité.

  • Rôles de base : rôles très permissifs qui offrent un accès étendu aux servicesGoogle Cloud . Ces rôles peuvent être utiles à des fins de test, mais ne doivent pas être utilisés dans les environnements de production.

Pour en savoir plus sur les rôles et les autorisations, consultez Rôles et autorisations.

Ressources

La plupart des services Google Cloud ont leurs propres ressources. Par exemple, Compute Engine dispose de ressources telles que des instances, des disques et des sous-réseaux.

Dans IAM, vous attribuez des rôles sur une ressource. Accorder un rôle à un compte principal sur une ressource signifie que le compte principal peut utiliser les autorisations de ce rôle pour accéder à la ressource.

Vous pouvez attribuer des rôles à un sous-ensemble de ressources Google Cloud . Pour obtenir la liste complète des ressources sur lesquelles vous pouvez attribuer des rôles, consultez Types de ressources compatibles avec les stratégies d'autorisation.

Google Cloud dispose également de plusieurs ressources de conteneur, y compris des projets, des dossiers et des organisations. Si vous accordez un rôle à un compte principal sur une ressource conteneur, il aura accès à la ressource conteneur et aux ressources qu'elle contient. Cette fonctionnalité vous permet d'utiliser une seule attribution de rôle pour donner à un compte principal l'accès à plusieurs ressources, y compris celles sur lesquelles vous ne pouvez pas attribuer de rôles directement. Pour en savoir plus, consultez la section Héritage des règles sur cette page.

Règles d'autorisation

Vous attribuez des rôles aux comptes principaux à l'aide de stratégies d'autorisation. Par le passé, ces stratégies étaient appelées stratégies IAM.

Une stratégie d'autorisation est un objet YAML ou JSON associé à une ressource Google Cloud.

Le schéma suivant montre la structure d'une stratégie d'autorisation :

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

Chaque stratégie d'autorisation contient une liste de liaisons de rôles qui associent des rôles IAM aux comptes principaux auxquels ces rôles sont attribués.

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 le compte principal dispose des autorisations requises. Si le compte principal est associé à une liaison de rôle qui inclut un rôle doté des autorisations requises, il est autorisé à accéder à la ressource.

Pour voir des exemples de stratégies d'autorisation et en savoir plus sur leur structure, consultez Comprendre les stratégies d'autorisation.

Héritage des règles

Google Cloud dispose de ressources de conteneur, telles que des projets, des dossiers et des organisations, qui vous permettent d'organiser vos ressources dans une hiérarchie parent-enfant. Cette hiérarchie est appelée hiérarchie des ressources.

La hiérarchie des ressources Google Cloud présente la structure suivante :

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

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

Hiérarchie des ressources IAM

Si vous définissez une stratégie d'autorisation sur une ressource de conteneur, elle s'applique également à toutes les ressources de ce conteneur. Ce concept est appelé héritage des stratégies, car les ressources descendantes héritent effectivement des stratégies d'autorisation de leurs ressources ascendantes.

L'héritage des règles a les implications suivantes :

  • Vous pouvez utiliser une seule liaison de rôle pour accorder l'accès à plusieurs ressources. Si vous souhaitez donner à un compte principal l'accès à toutes les ressources d'un conteneur, attribuez-lui un rôle sur le conteneur plutôt que sur les ressources qu'il contient.

    Par exemple, si vous souhaitez autoriser votre administrateur de sécurité à gérer les stratégies d'autorisation pour toutes les ressources de votre organisation, vous pouvez lui attribuer le rôle Administrateur de sécurité (roles/iam.securityAdmin) au niveau de l'organisation.

  • Vous pouvez accorder l'accès à des ressources qui ne disposent pas de leur propre stratégie d'autorisation. Toutes les ressources n'acceptent pas les stratégies d'autorisation, mais toutes les ressources héritent des stratégies d'autorisation de leurs ancêtres. Pour accorder à un compte principal l'accès à une ressource qui ne peut pas avoir sa propre stratégie d'autorisation, attribuez-lui un rôle sur l'un des ancêtres de la ressource.

    Par exemple, imaginons que vous souhaitiez autoriser un utilisateur à écrire des journaux dans un bucket de journaux. Les buckets de journaux ne disposent pas de leurs propres stratégies d'autorisation. Pour accorder cette autorisation à un utilisateur, vous pouvez lui attribuer le rôle "Auteur de buckets de journaux" (roles/logging.bucketWriter) sur le projet contenant le bucket de journaux.

  • Pour savoir qui peut accéder à une ressource, vous devez également afficher toutes les stratégies d'autorisation qui affectent la ressource. Pour obtenir la liste complète des principaux ayant accès à la ressource, vous devez afficher la stratégie d'autorisation de la ressource et celles de ses ancêtres. L'union de toutes ces stratégies est appelée stratégie d'autorisation applicable.

Pour en savoir plus sur l'héritage des stratégies d'autorisation, consultez Utiliser la hiérarchie des ressources pour le contrôle des accès.

Contrôle d'accès avancés

En plus des stratégies d'autorisation, IAM fournit les mécanismes de contrôle d'accès suivants pour vous aider à affiner qui a accès à quelles ressources :

  • Types de stratégies supplémentaires : en plus des stratégies d'autorisation, IAM propose les types de stratégies suivants :

    • Stratégies de refus : elles empêchent les comptes principaux d'utiliser certaines autorisations, même si un rôle leur est attribué avec cette autorisation.

    • Stratégies de limite d'accès des comptes principaux (PAB) : ces stratégies définissent les ressources auxquelles un compte principal est autorisé à accéder et appliquent cette limite. Les comptes principaux ne peuvent pas accéder aux ressources auxquelles ils ne sont pas autorisés, même si un rôle leur a été attribué sur la ressource.

    Pour en savoir plus sur ces règles, consultez Types de règles.

  • Conditions IAM : les conditions IAM vous permettent de définir et d'appliquer un contrôle des accès conditionnel basé sur des attributs. Vous pouvez utiliser des conditions dans différents types de règles. Par exemple, vous pouvez ajouter une condition à une liaison de rôle dans une stratégie d'autorisation pour vous assurer que le rôle n'est accordé que si la condition est remplie.

    Vous pouvez écrire des conditions basées sur des attributs tels que la ressource dans la requête et l'heure de la requête.

    Pour en savoir plus sur les conditions IAM, consultez la présentation des conditions IAM.

  • Privileged Access Manager (PAM) : avec Privileged Access Manager, vous pouvez autoriser les comptes principaux à demander et à obtenir un accès temporaire et auditable aux ressources. Par exemple, vous pouvez exiger que les principaux demandent l'accès chaque fois qu'ils souhaitent afficher une ressource sensible, au lieu de leur accorder un rôle IAM de manière permanente.

    Vous pouvez également configurer si les principaux doivent fournir des justifications ou obtenir des approbations lorsqu'ils demandent l'accès.

    Pour en savoir plus sur Privileged Access Manager, consultez Présentation de Privileged Access Manager.

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.

Étapes suivantes

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