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 Cloud de Confiance.
Utiliser des principaux dans vos règles
Pour utiliser des principaux dans vos règles, procédez comme suit :
Configurez les identités que Cloud de Confiance peut reconnaître. La configuration des identités consiste à créer des identités que Cloud de Confiance 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 règle 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 acceptés pour 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 règle, 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 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 :
|
| Ensemble de comptes de service | Tous les comptes de service d'un projet, d'un dossier ou d'une organisation. | Ensemble de comptes principaux contenant des comptes de service. | Géré par Google |
Les types de règles suivants sont compatibles avec un ensemble de comptes de service :
|
| Ensemble d'agents de service | Tous les comptes de service gérés par Google (agents de service) associés à un projet, un dossier ou une organisation. | Ensemble de comptes principaux contenant des agents de service. | Géré par Google |
Les types de règles suivants sont compatibles avec un ensemble d'agents de service :
Les types de règles suivants ne sont pas compatibles avec un ensemble d'agents de service :
|
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
|
| 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 :
|
Les sections suivantes décrivent ces principaux types plus en détail.
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. Les comptes de service peuvent être divisés en comptes de service gérés par l'utilisateur et en comptes de service gérés par Google, appelés agents de service :
Lorsque vous exécutez du code hébergé sur Cloud de Confiance, vous spécifiez un compte de service à utiliser comme identité pour votre application. Vous pouvez créer autant de comptes de service gérés par l'utilisateur que nécessaire pour représenter les différents composants logiques de votre application.
Certains services Cloud de Confiance ont besoin d'accéder à vos ressources pour pouvoir agir en votre nom. Pour répondre à ce besoin, Google crée et gère des agents de service.
Vous pouvez faire référence aux comptes de service et aux agents de service de différentes manières :
- Un seul compte de service
- Tous les comptes de service d'un projet
- Tous les agents de service associés à un projet.
- Tous les comptes de service de tous les projets d'un dossier
- Tous les agents de service associés à un dossier et à ses descendants
- Tous les comptes de service de tous les projets d'une organisation
- Tous les agents de service associés à une organisation et à ses descendants
Les exemples suivants montrent comment identifier un compte de service individuel dans différents types de règles :
- Un compte de service dans les stratégies d'autorisation :
serviceAccount:my-service-account@my-project.s3ns.iam.gserviceaccount.com - Compte de service dans les règles de refus :
principal://iam.googleapis.com/projects/-/serviceAccounts/my-service-account@my-project.s3ns.iam.gserviceaccount.com
Les exemples suivants montrent comment identifier tous les comptes de service pour un projet, un dossier ou une organisation dans différents types de règles :
- Tous les comptes de service d'un projet dans les règles d'autorisation :
principalSet://cloudresourcemanager.googleapis.com/projects/123456789012/type/ServiceAccount - Tous les agents de service associés à un dossier dans les règles de refus :
principalSet://cloudresourcemanager.googleapis.com/folders/123456789012/type/ServiceAgent
Pour en savoir plus sur les formats des identifiants principaux, consultez Identifiants principaux.
Pour en savoir plus sur les comptes de service, consultez les pages suivantes :
allAuthenticatedUsers
La valeur allAuthenticatedUsers est un identifiant spécial qui représente tous les comptes de service.
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. Pour inclure des identités fédérées, choisissez l'une des options 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 :
- Identité unique dans les règles d'autorisation :
principal://iam.googleapis.com/locations/global/workforcePools/altostrat-contractors/subject/raha@altostrat.com - Groupe d'identités dans les règles de refus :
principalSet://iam.googleapis.com/locations/global/workforcePools/altostrat-contractors/group/administrators-group@altostrat.com
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 règles :
- Identité unique dans les règles d'autorisation :
principal://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/altostrat-contractors/subject/raha@altostrat.com - Groupe d'identités dans les règles de refus :
principalSet://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/altostrat-contractors/group/administrators-group@altostrat.com
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 Cloud de Confiance . 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.s3ns.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.
É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