Dans Identity and Access Management (IAM), vous contrôlez l'accès des comptes principaux. Un compte principal représente une ou plusieurs identités authentifiées auprès de Google Cloud.
Utiliser des principaux dans vos règles
Pour utiliser des principaux dans vos règles, procédez comme suit :
Configurez les identités que Google Cloud peut reconnaître. La configuration des identités consiste à créer des identités que Google Cloud peut reconnaître. Vous pouvez configurer des identités pour les utilisateurs et les charges de travail.
Pour savoir comment configurer les identités, consultez les ressources suivantes :
- Pour savoir comment configurer les identités des utilisateurs, consultez Identités pour les utilisateurs.
- Pour savoir comment configurer des identités pour les charges de travail, consultez Identités pour les charges de travail.
Déterminez l'identifiant principal que vous utiliserez. L'identifiant principal est la façon dont vous faites référence à un principal dans vos règles. Cet identifiant peut faire référence à une identité unique ou à un groupe d'identités.
Le format que vous utilisez pour l'identifiant du compte principal dépend des éléments suivants :
- Type de compte principal
- Type de stratégie dans laquelle vous souhaitez inclure le compte principal
Pour connaître le format de l'identifiant principal pour chaque type de compte principal dans chaque type de règle, consultez Identifiants principaux.
Une fois que vous connaissez le format de l'identifiant, vous pouvez déterminer l'identifiant unique du compte principal en fonction de ses attributs, tels que son adresse e-mail.
Incluez l'identifiant du compte principal dans votre règle. Ajoutez votre compte principal à votre règle, en respectant le format de la règle.
Pour en savoir plus sur les différents types de règles dans IAM, consultez Types de règles.
Compatibilité avec les types de comptes principaux
Chaque type de stratégie IAM est compatible avec un sous-ensemble des types de comptes principaux acceptés par IAM. Pour connaître les types de comptes principaux compatibles avec chaque type de règle, consultez Identifiants principaux.
Types de comptes principaux
Le tableau suivant décrit brièvement les différents types de comptes principaux compatibles avec IAM. Pour obtenir une description détaillée et des exemples de la façon dont un type de principal peut se présenter lorsqu'il est utilisé dans une stratégie, cliquez sur le nom du type de principal dans le tableau.
| Type de compte principal | Description | Un seul compte principal ou un ensemble de comptes principaux | Géré par Google ou fédéré | Compatibilité des types de règles |
|---|---|---|---|---|
| Comptes Google | Comptes utilisateur représentant une personne qui interagit avec les API et les services Google. | Un seul compte principal | Géré par Google |
Les types de règles suivants sont compatibles avec les comptes Google :
Les types de règles suivants ne sont pas compatibles avec les comptes Google :
|
| Comptes de service | Compte utilisé par une charge de travail machine plutôt que par une personne. | Un seul compte principal | Géré par Google |
Les types de règles suivants sont compatibles avec les comptes de service :
Les types de règles suivants ne sont pas compatibles avec les comptes de service :
|
| Groupes Google | collection nommée d'utilisateurs humains ou automatiques disposant de comptes Google. |
Ensemble de comptes principaux pouvant contenir les éléments suivants :
|
Géré par Google |
Les types de règles suivants sont compatibles avec les groupes Google :
Les types de règles suivants ne sont pas compatibles avec les groupes Google :
|
| Domaines | Un compte Google Workspace ou un domaine Cloud Identity représentant un groupe virtuel. Le groupe peut contenir à la fois des utilisateurs humains et des comptes de service. |
Ensemble de comptes principaux pouvant contenir les types de comptes principaux suivants :
|
Géré par Google |
Les types de règles suivants sont compatibles avec les domaines :
|
allAuthenticatedUsers |
Identifiant spécial qui représente tous les comptes de service et tous les internautes qui se sont authentifiés avec un compte Google. |
Ensemble de comptes principaux pouvant contenir les types de comptes principaux suivants :
|
Géré par Google |
Les types de règles suivants sont compatibles avec
Les types de règles suivants ne sont pas compatibles avec
|
allUsers |
Identifiant spécial qui représente toute personne ayant accès à Internet, qu'elle soit authentifiée ou non. |
Ensemble de comptes principaux pouvant contenir les types de comptes principaux suivants :
|
Les deux |
Les types de règles suivants sont compatibles avec
Les types de règles suivants ne sont pas compatibles avec
|
| Identité unique d'un pool d'identités de personnel | Utilisateur humain dont l'identité est gérée par un IdP externe et fédérée à l'aide de la fédération des identités des employés. | Un seul compte principal | Fédéré |
Les types de règles suivants sont compatibles avec une identité unique dans un pool d'identités de personnel :
|
| Ensemble de comptes principaux dans un pool d'identités de personnel | Ensemble d'utilisateurs humains dont les identités sont gérées par un IdP externe et fédérées à l'aide de la fédération des identités des employés. | Ensemble de comptes principaux contenant des identités de personnel. | Fédéré |
Les types de stratégies suivants sont compatibles avec un ensemble de principaux dans un pool d'identités de personnel :
|
| Un seul principal dans un pool d'identités de charge de travail | Charge de travail (ou utilisateur machine) avec une identité gérée par un IdP externe et fédérée à l'aide de la fédération d'identité de charge de travail. | Un seul compte principal | Fédéré |
Les types de règles suivants sont compatibles avec une seule entité principale dans un pool d'identités de charge de travail :
|
| Ensemble de comptes principaux dans un pool d'identités de charge de travail | Ensemble de charges de travail (ou d'utilisateurs de machines) dont les identités sont gérées par un IdP externe et fédérées à l'aide de la fédération d'identité de charge de travail. | Ensemble de comptes principaux contenant des identités de charge de travail | Fédéré |
Les types de règles suivants sont compatibles avec un ensemble de principaux dans un pool d'identités de charge de travail :
|
| Ensemble de pods Google Kubernetes Engine | Charge de travail (ou utilisateur machine) exécutée sur GKE et fédérée via GKE. | Ensemble de comptes principaux pouvant contenir une ou plusieurs identités de charge de travail fédérées | Fédéré |
Les types de règles suivants sont compatibles avec les pods GKE :
Les types de règles suivants ne sont pas compatibles avec les pods GKE :
|
| Ensembles de principaux Resource Manager | Ensemble d'utilisateurs humains ou automatiques associés à des ressources Google Cloud telles que des projets, des dossiers et des organisations. |
Ensemble de comptes principaux pouvant contenir les types de comptes principaux suivants :
|
Les deux |
Les types de règles suivants sont compatibles avec les ensembles de comptes principaux Resource Manager :
Les types de règles suivants ne sont pas compatibles avec les ensembles de comptes principaux Resource Manager :
|
Les sections suivantes décrivent ces principaux types plus en détail.
Comptes Google
Un compte Google représente un développeur, un administrateur ou toute autre personne qui interagit avec Google Cloud à l'aide d'un compte qu'elle a créé avec Google. Toute adresse e-mail associée à un compte Google, également appelé compte utilisateur géré, peut être utilisée comme principal. Cela inclut les adresses e-mail gmail.com et les adresses e-mail avec d'autres domaines.
Les exemples suivants montrent comment identifier un compte Google dans différents types de règles :
- Règles "Autoriser" :
user:alex@example.com - Règles de refus :
principal://goog/subject/alex@example.com
Pour en savoir plus sur les formats des identifiants principaux, consultez Identifiants principaux.
Dans vos règles d'autorisation et de refus, les alias d'adresse e-mail associés à un compte Google ou à un compte utilisateur géré sont automatiquement remplacés par l'adresse e-mail principale. Cela signifie que le règlement affiche l'adresse e-mail principale de l'utilisateur lorsque vous accordez l'accès à un alias d'adresse e-mail.
Pour en savoir plus sur la configuration des comptes Google, consultez Comptes Cloud Identity ou Google Workspace.
Comptes 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é surGoogle Cloud, vous spécifiez un compte de service à utiliser comme identité pour votre application. Vous pouvez créer autant de comptes de service que nécessaire pour représenter les différents composants logiques de votre application.
Les exemples suivants montrent comment identifier un compte de service dans différents types de règles :
- Règles "Autoriser" :
serviceAccount:my-service-account@my-project.iam.gserviceaccount.com - Règles de refus :
principal://iam.googleapis.com/projects/-/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com
Pour en savoir plus sur les formats des identifiants principaux, consultez Identifiants principaux.
Pour en savoir plus sur les comptes de service, consultez la présentation des comptes de service.
Groupes Google
Un groupe Google est une collection nommée de comptes Google. 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 de principaux. Vous pouvez accorder et modifier les accès pour tout un groupe à la fois, plutôt que d'effectuer cette action pour chaque principal individuel. Vous pouvez également ajouter des comptes principaux à un groupe Google ou en supprimer, au lieu de mettre à jour une stratégie d'autorisation pour ajouter ou supprimer des comptes principaux.
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.
Les exemples suivants montrent comment identifier un groupe Google dans différents types de règles :
- Règles "Autoriser" :
group:my-group@example.com - Règles de refus :
principalSet://goog/group/my-group@example.com
Pour en savoir plus sur les formats des identifiants principaux, consultez Identifiants principaux.
Pour en savoir plus sur l'utilisation des groupes pour le contrôle des accès, consultez Bonnes pratiques pour utiliser les groupes Google.
Domaines
Les domaines peuvent exister en tant que comptes Google Workspace ou domaines Cloud Identity. Ils sont fondamentalement identiques, car ils représentent tous les deux un groupe virtuel de tous les comptes Google qu'ils contiennent. La seule différence est que les utilisateurs de domaines Cloud Identity n'ont pas accès aux applications et aux fonctionnalités de Google Workspace.
Les comptes Google Workspace et les domaines Cloud Identity sont associés au nom de domaine Internet de votre organisation, tel que 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 ou de votre domaine Cloud Identity.
Comme les groupes Google, les domaines ne peuvent pas être utilisés pour établir une identité, mais ils permettent une gestion pratique des autorisations.
Les exemples suivants montrent comment identifier un domaine dans différents types de règles :
- Règles "Autoriser" :
domain:example.com - Règles de refus :
principalSet://goog/cloudIdentityCustomerId/C01Abc35 - Stratégies de limite d'accès des comptes principaux :
//iam.googleapis.com/locations/global/workspace/C01Abc35
Pour en savoir plus sur les formats des identifiants principaux, consultez Identifiants principaux.
Pour en savoir plus sur Cloud Identity, consultez À propos de Cloud Identity.
Dans vos règles d'autorisation et de refus, les domaines secondaires sont automatiquement remplacés par le domaine principal. Cela signifie que la stratégie affiche le domaine principal lorsque vous accordez l'accès à un domaine secondaire.
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 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 fédérées, qui sont gérées par des 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 :
- Pour inclure les utilisateurs de tous les IdP, utilisez
allUsers. - Pour inclure les utilisateurs d'IdP externes spécifiques, utilisez l'identifiant pour toutes les identités d'un pool d'identités de personnel ou toutes les identités d'un pool d'identités de charge de travail.
Certains types de ressources ne sont pas compatibles avec ce type de compte principal.
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.
Certains types de ressources ne sont pas compatibles avec ce type de compte principal.
Les exemples suivants montrent à quoi peut ressembler l'identifiant allUsers dans différents types de règles :
- Stratégies d'autorisation sur les types de ressources compatibles :
allUsers - Règles de refus :
principalSet://goog/public:all
Pour en savoir plus sur les formats des identifiants principaux, consultez Identifiants principaux.
Identités fédérées dans un pool d'identités de personnel
Un pool d'identité de personnel est un ensemble d'identités utilisateur géré par un IdP externe et fédéré à l'aide de la fédération des identités des employés. Vous pouvez référencer les comptes principaux de ces pools de différentes manières :
- Identité unique d'un pool d'identités de personnel
- Toutes les identités de personnel d'un groupe spécifié
- Toutes les identités de personnel porteuses d'une valeur d'attribut spécifique
- Toutes les identités d'un pool d'identités de personnel
Les exemples suivants montrent comment identifier les pools d'identité de personnel fédérés dans différents types de stratégies :
- Un seul compte principal dans les stratégies d'autorisation :
principal://iam.googleapis.com/locations/global/workforcePools/altostrat-contractors/subject/raha@altostrat.com - Ensemble de comptes principaux dans les règles de refus :
principalSet://iam.googleapis.com/locations/global/workforcePools/altostrat-contractors/group/administrators-group@altostrat.com - Stratégies de limite d'accès des comptes principaux :
//iam.googleapis.com/locations/global/workforcePools/example-workforce-pool
Pour en savoir plus sur les formats des identifiants principaux, consultez Identifiants principaux.
Identités fédérées dans un pool d'identités de charge de travail
Un pool d'identités de charge de travail est un ensemble d'identités de charge de travail gérées par un IdP externe et fédérées à l'aide de la fédération d'identité de charge de travail. Vous pouvez référencer les comptes principaux de ces pools de différentes manières :
- Une identité unique dans un pool d'identités de charge de travail
- Toutes les identités de charge de travail d'un groupe spécifié
- Toutes les identités de charge de travail porteuses d'une valeur d'attribut spécifique
- Toutes les identités d'un pool d'identités de charge de travail
Les exemples suivants montrent comment identifier les pools d'identités de charge de travail fédérées dans différents types de stratégies :
- Un seul compte principal dans les stratégies d'autorisation :
principal://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/altostrat-contractors/subject/raha@altostrat.com - Groupe de comptes principaux dans les règles de refus :
principalSet://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/altostrat-contractors/group/administrators-group@altostrat.com - Stratégies de limite d'accès des comptes principaux :
//iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/example-workload-pool
Pour en savoir plus sur les formats des identifiants principaux, consultez Identifiants principaux.
Pods GKE
Les charges de travail exécutées sur GKE utilisent Workload Identity Federation for GKE pour accéder aux services Google Cloud . Pour en savoir plus sur les identifiants principaux des pods GKE, consultez Faire référence aux ressources Kubernetes dans les stratégies IAM.
L'exemple suivant montre comment identifier tous les pods GKE d'un cluster spécifique dans une stratégie d'autorisation :
principalSet://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/123456789012.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/123456789012/locations/global/clusters/example-gke-cluster
Pour en savoir plus sur les formats des identifiants principaux, consultez Identifiants principaux.
Ensembles de comptes principaux Resource Manager
Chaque ressource Resource Manager (projets, dossiers et organisations) est associée à un ensemble de comptes principaux. Lorsque vous créez des liaisons de stratégie de limite d'accès des comptes principaux, vous pouvez utiliser l'ensemble de comptes principaux d'une ressource Resource Manager pour faire référence à tous les comptes principaux associés à cette ressource.
Les ensembles de comptes principaux pour les ressources Resource Manager contiennent les comptes principaux suivants :
- Ensemble de comptes principaux du projet : tous les comptes de service et pools d'identités de charge de travail du projet spécifié.
- Ensemble de comptes principaux du dossier : tous les comptes de service et tous les pools d'identités de charge de travail de n'importe quel projet du dossier spécifié.
Ensemble de comptes principaux de l'organisation : contient les identités suivantes :
- Toutes les identités de tous les domaines associés à votre numéro client Google Workspace
- Tous les pools d'identités de personnel de votre organisation
- Tous les comptes de service et pools d'identités de charge de travail de n'importe quel projet de l'organisation
L'exemple suivant montre comment identifier l'ensemble de comptes principaux d'un projet dans une stratégie de limite d'accès des comptes principaux pour l'ensemble de comptes principaux d'un projet :
//cloudresourcemanager.googleapis.com/projects/example-project
Pour en savoir plus sur les formats des identifiants principaux, consultez Identifiants principaux.
Étapes suivantes
- En savoir plus sur les types de stratégies compatibles avec IAM
- Attribuer un rôle à un compte principal sur un projet, un dossier ou une organisation Resource Manager