Cette page décrit le fonctionnement du système IAM (Identity and Access Management) de Google Cloudet explique comment l'utiliser pour gérer les accès dans Google Cloud.
IAM est un outil permettant de gérer l'autorisation précise 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 suivre les trois étapes suivantes:
- Principal: identité de la personne ou du système à qui vous souhaitez accorder des autorisations
- Rôle: ensemble d'autorisations que vous souhaitez accorder au compte principal
- Resource (Ressource) : ressource Google Cloud que vous souhaitez autoriser le principal à accéder
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.
Ces concepts sont décrits plus en détail dans les sections suivantes.
Comptes principaux
Dans Google Cloud , vous contrôlez l'accès des principals. Les principaux représentent une ou plusieurs identités qui se sont authentifiées auprès de Google Cloud.
Auparavant, 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 d'entités principales 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 des employés.
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 les ressourcesGoogle Cloud d'accès de vos charges de travail.
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 la section 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. Les autorisations correspondent souvent 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 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 des 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 Éditeur 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 avez le contrôle total sur les autorisations de ces rôles. Toutefois, ils nécessitent une charge de maintenance plus importante que les rôles prédéfinis, et le nombre de rôles personnalisés que vous pouvez avoir dans votre projet et dans 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 la section Rôles et autorisations.
Ressources
La plupart des services Google Cloud disposent de 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 à 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 auxquelles vous pouvez attribuer des rôles, consultez la section Types de ressources compatibles avec les stratégies d'autorisation.
Google Cloud comporte également plusieurs ressources de conteneur, y compris des projets, des dossiers et des organisations. Accorder un rôle à un compte principal sur une ressource de conteneur lui donne accès à la ressource de conteneur et aux ressources de ce conteneur. Cette fonctionnalité vous permet d'utiliser une seule autorisation de rôle pour accorder à un principal l'accès à plusieurs ressources, y compris celles auxquelles vous ne pouvez pas attribuer directement de rôles. Pour en savoir plus, consultez la section Héritage des stratégies sur cette page.
Règles d'autorisation
Vous attribuez des rôles aux comptes principaux à l'aide de stratégies d'autorisation. Auparavant, 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:
Chaque stratégie d'autorisation contient une liste de liaisons de rôles qui associent les rôles IAM aux comptes principaux auxquels ces rôles sont accordé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 fait partie d'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 la section Comprendre les stratégies d'autorisation.
Héritage des règles
Google Cloud contient des 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 :
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 de stratégie, car les ressources descendantes héritent effectivement des stratégies d'autorisation de leurs ressources ascendantes.
L'héritage de 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 accorder à 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 du conteneur.
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 accorder 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 leurs propres stratégies d'autorisation. Toutes les ressources n'acceptent pas les stratégies d'autorisation, mais toutes 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 disposer de 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 n'ont pas leurs propres stratégies d'autorisation. Pour accorder cette autorisation à un utilisateur, vous pouvez lui attribuer le rôle "Écrivain de bucket 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 les stratégies d'autorisation de ses ancêtres. L'union de toutes ces stratégies est appelée stratégie d'autorisation effective.
Pour en savoir plus sur l'héritage des stratégies pour les stratégies d'autorisation, consultez la section 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 des accès suivants pour vous aider à affiner les droits d'accès des utilisateurs aux ressources:
Types de stratégies supplémentaires: IAM propose les types de stratégies suivants en plus des stratégies d'autorisation:
Stratégies de refus: les stratégies de refus empêchent les comptes principaux d'utiliser certaines autorisations, même s'ils disposent d'un rôle avec l'autorisation.
Stratégies de limite d'accès des comptes principaux (PAB, Principal Access Boundary): les stratégies de limite d'accès des comptes principaux définissent et appliquent les ressources auxquelles un compte principal peut accéder. Les comptes principaux ne peuvent pas accéder aux ressources auxquelles ils n'ont pas le droit d'accéder, même s'ils ont reçu un rôle sur la ressource.
Pour en savoir plus sur ces règles, consultez la section Types de règles.
Conditions IAM: les conditions IAM vous permettent de définir et d'appliquer un contrôle d'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 en fonction d'attributs tels que la ressource de la requête et l'heure de la requête.
Pour en savoir plus sur les conditions IAM, consultez la page Présentation des conditions IAM.
Gestionnaire d'accès privilégié (PAM): avec Privileged Access Manager, vous pouvez autoriser les principaux à demander 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 la section 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.
Étape suivante
- Pour savoir comment configurer des identités pour Google Cloud, consultez la section Gestion des identités pour Google Cloud.
- Pour découvrir comment attribuer, modifier et révoquer des rôles Cloud IAM pour les comptes principaux, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.
- Pour obtenir la liste des rôles IAM disponibles, consultez la section Rôles prédéfinis.
- 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 en savoir plus sur les types de stratégies disponibles dans IAM, consultez la section Types de stratégies.
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