Utiliser des règles d'administration personnalisées pour les règles d'autorisation

Cette page vous explique comment utiliser les contraintes personnalisées du service de règles d'administration pour restreindre des opérations spécifiques sur les ressources Google Cloud suivantes :

• iam.googleapis.com/AllowPolicy

Pour en savoir plus sur les règles d'administration, consultez Règles d'administration personnalisées.

À propos des règles et des contraintes d'administration

Le service de règles d'administration Google Cloud vous offre un contrôle centralisé et automatisé sur les ressources de votre organisation. En tant qu'administrateur des règles d'administration, vous pouvez définir des ensembles de restrictions appelées contraintes qui s'appliquent aux ressourcesGoogle Cloud et à leurs descendants dans la hiérarchie des ressourcesGoogle Cloud . Chaque ensemble de restrictions constitue une règle d'administration. Vous pouvez appliquer des règles d'administration au niveau d'une organisation, d'un dossier ou d'un projet.

Les règles d'administration fournissent des contraintes gérées intégrées pour divers services Google Cloud . Toutefois, si vous souhaitez exercer un contrôle plus précis et le personnaliser pour des champs spécifiques restreints dans vos règles d'administration, vous pouvez également créer des contraintes personnalisées et les utiliser dans une règle d'administration.

Héritage des règles

Par défaut, les règles d'administration sont héritées par les descendants des ressources sur lesquelles vous les appliquez. Par exemple, si vous appliquez une règle au niveau d'un dossier, Google Cloud l'applique à tous les projets du dossier. Pour mieux comprendre ce comportement et savoir comment le modifier, consultez Règles d'évaluation hiérarchique.

Avantages

Vous pouvez utiliser des règles d'administration personnalisées qui font référence à des attributs IAM pour contrôler la manière dont vos stratégies d'autorisation peuvent être modifiées. Plus précisément, vous pouvez contrôler les éléments suivants :

• Qui peut se voir attribuer des rôles
• Qui peut se voir retirer ses rôles
• Rôles pouvant être attribués
• Rôles pouvant être révoqués

Par exemple, vous pouvez empêcher que les rôles contenant le mot admin soient attribués aux comptes principaux dont l'adresse e-mail se termine par @gmail.com.

Limites

• Règles d'administration personnalisées en mode dry run qui font référence à des attributs IAM présentent certaines limites. Plus précisément, les journaux d'audit des cas de non-respect impliquant la méthode setIamPolicy peuvent ne pas comporter les champs suivants :

  • resourceName
  • serviceName
  • methodName

• Les journaux d'audit ne sont pas générés pour tous les cas de non-respect des règles d'entreprise personnalisées liées à IAM. Plus précisément, si une règle d'administration personnalisée entraîne l'échec d'une opération setIamPolicy sur la ressource d'organisation,Google Cloud ne génère pas de journal d'audit pour cet événement.

• Règles d'administration personnalisées qui font référence aux attributs IAM n'affectent pas les éléments suivants :

  • Autorisations par défaut par LCA Cloud Storage.
  • Attribution automatique de rôles pour les valeurs de commodité Cloud Storage et l'accès à l'ensemble de données BigQuery par défaut.
  • Rôles accordés par les stratégies d'autorisation par défaut (par exemple, le rôle Propriétaire (roles/owner) est automatiquement accordé au créateur d'un projet).

• Vous pouvez envoyer des invitations à des utilisateurs pour qu'ils deviennent propriétaires, même si vous avez une règle d'organisation personnalisée qui empêche l'attribution du rôle de propriétaire (roles/owner). Toutefois, même si la règle d'administration personnalisée n'empêche pas l'envoi d'une invitation, elle empêche l'attribution du rôle de propriétaire aux utilisateurs invités. Si les utilisateurs invités tentent d'accepter l'invitation, ils rencontreront une erreur et le rôle de propriétaire ne leur sera pas attribué.

• Certaines actions dans Google Cloud, comme la création de ressources ou l'activation d'API, impliquent l'attribution automatique d'un rôle à un agent de service ou à un compte de service par défaut. Si une action implique l'attribution automatique d'un rôle et qu'une règle d'administration empêche l'attribution de ce rôle, l'ensemble de l'opération peut échouer.

  Si vous rencontrez ce problème, vous pouvez utiliser des tags pour désactiver temporairement la contrainte qui empêche l'attribution du rôle. Ensuite, effectue l'action. Une fois l'action terminée, réactivez la contrainte.

Avant de commencer

• Si vous souhaitez tester des règles d'administration personnalisées qui font référence à des ressources IAM, créez un projet. Le test de ces règles d'administration dans un projet existant peut perturber les workflows de sécurité.

  1. In the Google Cloud console, go to the project selector page.

     Go to project selector

  2. Select or create a Google Cloud project.

     Roles required to select or create a project

     • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
     • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
     Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Rôles requis

Pour obtenir les autorisations nécessaires pour gérer les règles d'administration, demandez à votre administrateur de vous accorder les rôles IAM suivants :

• Administrateur des règles d'administration (roles/orgpolicy.policyAdmin) sur l'organisation
• Tester les règles d'administration décrites sur cette page : Administrateur de projet IAM (roles/resourcemanager.projectIamAdmin) sur le projet

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour gérer les règles d'administration. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour gérer les règles d'administration :

• orgpolicy.* sur l'organisation
• Testez les règles d'administration décrites sur cette page : resourcemanager.projects.setIamPolicy sur le projet

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Créer une contrainte personnalisée

Une contrainte personnalisée est définie dans un fichier YAML, qui spécifie les ressources, méthodes, conditions et actions compatibles avec le service auquel vous appliquez la règle d'administration. Les conditions de vos contraintes personnalisées sont définies à l'aide du langage CEL (Common Expression Language). Pour en savoir plus sur la création de conditions dans des contraintes personnalisées à l'aide du CEL, consultez la section CEL de la page Créer et gérer des contraintes personnalisées.

Pour créer une contrainte personnalisée, créez un fichier YAML au format suivant :

name: organizations/ORGANIZATION_ID/customConstraints/CONSTRAINT_NAME
resourceTypes:
- RESOURCE_NAME
methodTypes:
- CREATE
- UPDATE
condition: "CONDITION"
actionType: ACTION
displayName: DISPLAY_NAME
description: DESCRIPTION

Remplacez les éléments suivants :

• ORGANIZATION_ID : ID de votre organisation (par exemple, 123456789).

• CONSTRAINT_NAME : nom souhaité pour votre nouvelle contrainte personnalisée. Une contrainte personnalisée doit commencer par custom. et ne peut inclure que des lettres majuscules, minuscules ou des chiffres. Exemple : custom.denyProjectIAMAdmin. La longueur maximale de ce champ est de 70 caractères.

• RESOURCE_NAME : nom complet de la ressourceGoogle Cloud contenant l'objet et le champ que vous souhaitez restreindre. Par exemple, iam.googleapis.com/AllowPolicy.

• CONDITION : condition CEL écrite pour une représentation d'une ressource de service compatible. Ce champ ne doit pas comporter plus de 1 000 caractères. Consultez la section Ressources compatibles pour en savoir plus sur les ressources disponibles pour l'écriture de conditions. Par exemple, resource.bindings.exists(binding, RoleNameMatches(binding.role, ['roles/resourcemanager.projectIamAdmin'])).

• ACTION : action à effectuer si la condition est remplie. Les valeurs possibles sont ALLOW et DENY.

• DISPLAY_NAME : nom convivial de la contrainte. Ce champ ne doit pas comporter plus de 200 caractères.

• DESCRIPTION : description conviviale de la contrainte, qui sera affichée dans un message d'erreur en cas de non-respect de la règle. Ce champ ne doit pas comporter plus de 2 000 caractères.

Pour en savoir plus sur la création d'une contrainte personnalisée, consultez Définir des contraintes personnalisées.

Configurer une contrainte personnalisée

Après avoir créé le fichier YAML pour une nouvelle contrainte personnalisée, vous devez le configurer de sorte qu'il soit disponible pour les règles d'administration de votre organisation. Pour configurer une contrainte personnalisée, utilisez la commande gcloud org-policies set-custom-constraint :

gcloud org-policies set-custom-constraint CONSTRAINT_PATH

Remplacez CONSTRAINT_PATH par le chemin d'accès complet à votre fichier de contrainte personnalisée. Exemple : /home/user/customconstraint.yaml. Une fois l'opération terminée, vos contraintes personnalisées sont disponibles en tant que règles d'administration dans votre liste de règles d'administration Google Cloud . Pour vérifier que la contrainte personnalisée existe, utilisez la commande gcloud org-policies list-custom-constraints :

gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID

Remplacez ORGANIZATION_ID par l'ID de votre ressource d'organisation. Pour en savoir plus, consultez Afficher les règles d'administration.

Appliquer une règle d'administration personnalisée

Vous pouvez appliquer une contrainte en créant une règle d'administration qui y fait référence, puis en appliquant cette règle à une ressource Google Cloud .

Console

1. Dans la console Google Cloud , accédez à la page Règles d'administration.

   Accéder à la page Règles d'administration

2. Dans le sélecteur de projets, choisissez le projet pour lequel vous souhaitez définir la règle d'administration.
3. Dans la liste de la page Règles d'administration, sélectionnez votre contrainte pour afficher la page Détails de la règle de cette contrainte.
4. Pour personnaliser la règle d'administration pour cette ressource, cliquez sur Gérer la règle.
5. Sur la page Modifier la stratégie, sélectionnez Ignorer la règle parente.
6. Cliquez sur Ajouter une règle.
7. Dans la section Application, indiquez si l'application de cette règle d'administration est activée ou désactivée.
8. Facultatif : pour rendre la règle d'administration conditionnelle à un tag, cliquez sur Ajouter une condition. Notez que si vous ajoutez une règle conditionnelle à une règle d'administration, vous devez ajouter au moins une règle non conditionnelle, sinon la règle ne pourra pas être enregistrée. Pour en savoir plus, consultez Définir une règle d'administration avec des tags.
9. Cliquez sur Tester les modifications pour simuler l'effet de la règle d'administration. La simulation de règles n'est pas disponible pour les anciennes contraintes gérées. Pour en savoir plus, consultez Tester les modifications apportées aux règles d'administration à l'aide de Policy Simulator.
10. Pour terminer et appliquer la règle d'administration, cliquez sur Définir des règles. L'application de la règle peut prendre jusqu'à 15 minutes.

gcloud

Pour créer une règle d'administration avec des règles booléennes, créez un fichier YAML de règle qui fait référence à la contrainte :

      name: projects/PROJECT_ID/policies/CONSTRAINT_NAME
      spec:
        rules:
        - enforce: true
    

Remplacez les éléments suivants :

• PROJECT_ID : projet sur lequel vous souhaitez appliquer votre contrainte.
• CONSTRAINT_NAME : nom que vous avez défini pour la contrainte personnalisée. Exemple : custom.denyProjectIAMAdmin.

Pour appliquer la règle d'administration contenant la contrainte, exécutez la commande suivante :

    gcloud org-policies set-policy POLICY_PATH
    

Remplacez POLICY_PATH par le chemin d'accès complet au fichier YAML de votre règle d'administration. L'application de la règle peut prendre jusqu'à 15 minutes.

Tester la règle d'administration personnalisée

Vous pouvez éventuellement tester la règle d'administration en la définissant, puis en essayant d'effectuer une action qu'elle devrait empêcher.

Créer la contrainte

1. Enregistrez le fichier suivant sous le nom constraint-deny-project-iam-admin.

   name: organizations/ORG_ID/customConstraints/custom.denyProjectIAMAdmin
   resourceTypes: iam.googleapis.com/AllowPolicy
   methodTypes:
     - CREATE
     - UPDATE
   condition:
     "resource.bindings.exists(
       binding,
       RoleNameMatches(binding.role, ['roles/resourcemanager.projectIamAdmin']) &&
       binding.members.exists(member,
         MemberSubjectMatches(member, ['user:EMAIL_ADDRESS'])
       )
     )"
   actionType: DENY
   displayName: Do not allow EMAIL_ADDRESS to be granted the Project IAM Admin role.
   

   Remplacez les valeurs suivantes :

   • ORG_ID : ID numérique de votreGoogle Cloud organisation.
   • MEMBER_EMAIL_ADDRESS : adresse e-mail du compte principal que vous souhaitez utiliser pour tester la contrainte personnalisée. Tant que la contrainte est active, ce compte principal ne pourra pas se voir attribuer le rôle Administrateur IAM du projet (roles/resourcemanager.projectIamAdmin) sur le projet pour lequel la contrainte s'applique.

2. Appliquez la contrainte :

   gcloud org-policies set-custom-constraint ~/constraint-deny-project-iam-admin.yaml
   

3. Vérifiez que la contrainte existe :

   gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID
   

Créer la règle

1. Enregistrez le fichier suivant sous le nom policy-deny-project-iam-admin.yaml :

   name: projects/PROJECT_ID/policies/custom.denyProjectIamAdmin
   spec:
     rules:
     - enforce: true
   

   Remplacez PROJECT_ID par l'ID du projet.

2. Appliquez la règle :

   gcloud org-policies set-policy ~/policy-deny-project-iam-admin.yaml
   

3. Vérifiez que la règle existe :

   gcloud org-policies list --project=PROJECT_ID
   

Une fois la règle appliquée, attendez environ deux minutes que Google Cloud commence à l'appliquer.

Tester la stratégie

Essayez d'attribuer le rôle Administrateur IAM du projet (roles/resourcemanager.projectIamAdmin) au compte principal dont vous avez inclus l'adresse e-mail dans la contrainte personnalisée. Avant d'exécuter la commande, remplacez les éléments suivants :

• PROJECT_ID : ID du projet Google Clouddans lequel vous avez appliqué la contrainte
• EMAIL_ADDRESS : adresse e-mail du compte principal que vous avez spécifié lorsque vous avez créé la contrainte de règle d'administration.

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=user:EMAIL_ADDRESS --role=roles/resourcemanager.projectIamAdmin

Le résultat est le suivant :

Operation denied by custom org policies: ["customConstraints/custom.denyProjectIAMAdmin": "EMAIL_ADDRESS can't be granted the Project IAM Admin role."]

Exemples de règles d'administration personnalisées pour des cas d'utilisation courants

Le tableau suivant fournit la syntaxe de certaines contraintes personnalisées pour des cas d'utilisation courants.

Les exemples suivants utilisent les macros CEL all et exists. Pour en savoir plus sur ces macros, consultez Macros pour évaluer les listes.

Description	Syntaxe de la contrainte
Bloquer la possibilité d'attribuer un rôle spécifique.	name: organizations/ORG_ID/customConstraints/custom.denyRole resourceTypes: iam.googleapis.com/AllowPolicy methodTypes: - CREATE - UPDATE condition: "resource.bindings.exists( binding, RoleNameMatches(binding.role, ['ROLE']) )" actionType: DENY displayName: Do not allow the ROLE role to be granted
N'autorisez que l'attribution de rôles spécifiques.	name: organizations/ORG_ID/customConstraints/custom.specificRolesOnly resourceTypes: iam.googleapis.com/AllowPolicy methodTypes: - CREATE - UPDATE condition: "resource.bindings.all( binding, RoleNameMatches(binding.role, ['ROLE_1', 'ROLE_2']) )" actionType: ALLOW displayName: Only allow the ROLE_1 role and ROLE_2 role to be granted
Empêcher l'attribution de rôles commençant par roles/storage..	name: organizations/ORG_ID/customConstraints/custom.dontgrantStorageRoles resourceTypes: iam.googleapis.com/AllowPolicy methodTypes: - CREATE - UPDATE condition: "resource.bindings.exists( binding, RoleNameStartsWith(binding.role, ['roles/storage.']) )" actionType: DENY displayName: Prevent roles that start with "roles/storage." from being granted
Empêcher la révocation des rôles dont le nom contient admin.	name: organizations/ORG_ID/customConstraints/custom.dontRevokeAdminRoles resourceTypes: iam.googleapis.com/AllowPolicy methodTypes: - REMOVE_GRANT condition: "resource.bindings.exists( binding, RoleNameContains(binding.role, ['admin']) )" actionType: DENY displayName: Prevent roles with "admin" in their names from being revoked
N'autoriser que des comptes principaux spécifiques à se voir attribuer des rôles.	name: organizations/ORG_ID/customConstraints/custom.allowSpecificPrincipals resourceTypes: iam.googleapis.com/AllowPolicy methodTypes: - CREATE - UPDATE condition: "resource.bindings.all( binding, binding.members.all(member, MemberSubjectMatches(member, ['user:USER','serviceAccount:SERVICE_ACCOUNT']) ) )" actionType: ALLOW displayName: Only allow roles to be granted to USER and SERVICE_ACCOUNT
Empêcher la révocation de rôles pour des comptes principaux spécifiques.	name: organizations/ORG_ID/customConstraints/custom.denyRemovalOfSpecificPrincipals resourceTypes: iam.googleapis.com/AllowPolicy methodTypes: - REMOVE_GRANT condition: "resource.bindings.exists( binding, binding.members.exists(member, MemberSubjectMatches(member, ['user:USER_1','user:USER_2']) ) )" actionType: DENY displayName: Do not allow roles to be revoked from USER_1 or USER_2
Empêcher l'attribution de rôles aux comptes principaux dont l'adresse e-mail se termine par @gmail.com.	name: organizations/ORG_ID/customConstraints/custom.dontGrantToGmail resourceTypes: iam.googleapis.com/AllowPolicy methodTypes: - CREATE - UPDATE condition: "resource.bindings.exists( binding, binding.members.exists(member, MemberSubjectEndsWith(member, ['@gmail.com']) ) )" actionType: DENY displayName: Do not allow members whose email addresses end with "@gmail.com" to be granted roles
N'autorisez l'attribution de rôles spécifiques qu'à des comptes principaux spécifiques.	name: organizations/ORG_ID/customConstraints/custom.allowSpecificRolesAndPrincipals resourceTypes: iam.googleapis.com/AllowPolicy methodTypes: - CREATE - UPDATE condition: "resource.bindings.all( binding, RoleNameMatches(binding.role, ['ROLE_1', 'ROLE_2']) && binding.members.all(member, MemberSubjectMatches(member, ['serviceAccount:SERVICE_ACCOUNT', 'group:GROUP']) ) )" actionType: ALLOW displayName: Only allow ROLE_1 and ROLE_2 to be granted to SERVICE_ACCOUNT and GROUP
Empêcher l'attribution de rôles Cloud Storage à allUsers et allAuthenticatedUsers.	name: organizations/ORG_ID/customConstraints/custom.denyStorageRolesForPrincipalAllUsers resourceTypes: iam.googleapis.com/AllowPolicy methodTypes: - CREATE - UPDATE condition: "resource.bindings.exists( binding, RoleNameStartsWith(binding.role, ['roles/storage.']) && binding.members.exists(member, MemberSubjectMatches(member, ['allUsers', 'allAuthenticatedUsers']) ) )" actionType: DENY displayName: Do not allow storage roles to be granted to allUsers or allAuthenticatedUsers
Empêchez l'attribution de rôles à des identités extérieures à votre organisation.	name: organizations/ORG_ID/customConstraints/custom.allowInternaldentitiesOnly resourceTypes: iam.googleapis.com/AllowPolicy methodTypes: - CREATE - UPDATE condition: "resource.bindings.all( binding, binding.members.all(member, MemberInPrincipalSet(member, ['//cloudresourcemanager.googleapis.com/organizations/ORG_ID']) ) )" actionType: ALLOW displayName: Only allow organization members to be granted roles
Autoriser uniquement l'attribution de rôles aux comptes de service	name: organizations/ORG_ID/customConstraints/custom.allowServiceAccountsOnly resourceTypes: iam.googleapis.com/AllowPolicy methodTypes: - CREATE - UPDATE condition: "resource.bindings.all( binding, binding.members.all(member, MemberTypeMatches(member, ['iam.googleapis.com/ServiceAccount']) ) )" actionType: ALLOW displayName: Only allow service accounts to be granted roles
Empêchez la suppression des agents de service gérés par Google des liaisons de rôle.	name: organizations/ORG_ID/customConstraints/custom.denyRemovalOfGoogleManagedServiceAgents resource_types: iam.googleapis.com/AllowPolicy method_types: - REMOVE_GRANT condition: |- resource.bindings.all( binding, binding.members.all(member, MemberTypeMatches(member, ['iam.googleapis.com/ServiceAgent']) ) ) action_type: DENY display_name: Deny Removal Of Google-Managed Service Agents description: Restricts the removal of Google-managed service agents from role bindings. Please reach out to your organization admins for if you have any questions.

Règles d'administration conditionnelles

Vous pouvez rendre une règle d'administration personnalisée conditionnelle à l'aide de tags. Par exemple, imaginons que vous ayez écrit la contrainte personnalisée suivante pour empêcher l'attribution de rôles commençant par roles/storage. :

name: organizations/ORG_ID/customConstraints/custom.dontgrantStorageRoles
resourceTypes: iam.googleapis.com/AllowPolicy
methodTypes:
  - CREATE
  - UPDATE
condition:
  "resource.bindings.exists(
    binding,
    RoleNameStartsWith(binding.role, ['roles/storage.'])
  )"
actionType: DENY
displayName: Prevent roles that start with "roles/storage." from being granted

Pour appliquer la contrainte de manière conditionnelle, vous pouvez créer une règle d'administration comme suit :

name: organizations/ORG_ID/policies/custom.dontgrantStorageRoles
spec:
  rules:
  - condition:
      expression: "resource.matchTag('ORG_ID/environment', 'dev')"
    enforce: true
  - enforce: false

Cette règle d'administration empêche l'attribution de rôles commençant par roles/storage. sur toute ressource associée au tag environment=dev.

Ressources compatibles avec Identity and Access Management

IAM est compatible avec la ressource AllowPolicy. Cette ressource possède l'attribut resources.bindings, qui est renvoyé pour toutes les méthodes qui modifient la stratégie d'autorisation d'une ressource. Toutes les méthodes qui modifient la stratégie d'autorisation d'une ressource se terminent par setIamPolicy.

L'attribut resource.bindings a la structure suivante, où BINDINGS est un tableau de liaisons de rôle qui ont été modifiées lors de la modification d'une règle d'administration :

{
  "bindings": {
    BINDINGS
  }
}

Chaque liaison dans resource.bindings a la structure suivante, où ROLE est le nom du rôle dans la liaison de rôle et MEMBERS est une liste d'identifiants de tous les comptes principaux qui ont été ajoutés ou supprimés de la liaison de rôle :

{
  "role": "ROLE"
  "members": {
    MEMBERS
  }
}

Pour connaître les formats que peuvent avoir les identifiants des comptes principaux, consultez la section Identifiants des comptes principaux.

Vous ne pouvez évaluer l'attribut resource.bindings et ses champs qu'à l'aide des fonctions compatibles. Les autres opérateurs et fonctions, tels que ==, !=, in, contains, startsWith et endsWith, ne sont pas acceptés.

Fonctions compatibles

Vous pouvez utiliser les fonctions CEL suivantes pour évaluer les rôles et les membres individuels dans une liaison.

Pour évaluer toutes les liaisons du tableau bindings ou tous les membres du tableau members, utilisez les macros all et exists. Pour en savoir plus, consultez Macros pour évaluer les listes sur cette page.

Vous pouvez également utiliser les opérateurs logiques && (and) et || (or) pour écrire des conditions comportant plusieurs parties.

Fonction	Description
RoleNameMatches(   role,   roleNames: list )   bool	Renvoie true si le rôle role correspond entièrement à au moins l'un des rôles listés dans roleNames. Paramètres role : rôle à évaluer. roleNames : liste des noms de rôles à comparer. Exemple Renvoie true si le role dans le binding spécifié est roles/storage.admin ou roles/compute.admin: RoleNameMatches(binding.role, ['roles/storage.admin', 'roles/compute.admin'])
RoleNameStartsWith(   role,   rolePrefixes: list )   bool	Renvoie true si le rôle role commence par au moins l'une des chaînes listées dans rolePrefixes. Paramètres role : rôle à évaluer. rolePrefixes : liste de chaînes à faire correspondre au début du rôle. Exemple Renvoie true si le role dans le binding spécifié commence par roles/storage : RoleNameStartsWith(binding.role, ['roles/storage'])
RoleNameEndsWith(   role,   roleSuffixes: list )   bool	Renvoie true si le rôle role se termine par au moins l'une des chaînes listées dans roleSuffixes. Paramètres role : rôle à évaluer. roleSuffixes : liste de chaînes à faire correspondre à la fin du rôle. Exemple Renvoie true si le role dans le binding spécifié se termine par .admin : RoleNameEndsWith(binding.role, ['.admin'])
RoleNameContains(   role,   roleSubstrings: list )   bool	Renvoie true si le rôle role contient au moins l'une des chaînes listées dans roleSubstrings. Paramètres role : rôle à évaluer. roleSubstrings : liste de chaînes à faire correspondre à n'importe quelle partie du rôle. Exemple Renvoie true si le role dans le binding spécifié contient la chaîne admin : RoleNameContains(binding.role, ['admin'])
MemberSubjectMatches(   member,   memberNames: list )   bool	Renvoie true si le membre member correspond entièrement à au moins l'un des membres listés dans memberNames. Si l'identifiant de member est une adresse e-mail, cette fonction évalue l'adresse e-mail ainsi que tous les alias de cette adresse e-mail. Paramètres member : membre à évaluer. memberNames : liste des noms de membres à comparer. Exemple Renvoie true si le membre member est [e-mail] : MemberSubjectMatches(member, ['user:[e-mail]'])
MemberSubjectStartsWith(   member,   memberPrefixes: list )   bool	Renvoie true si le membre member commence par au moins l'une des chaînes listées dans memberPrefixes. Si l'identifiant de member est une adresse e-mail, cette fonction évalue l'adresse e-mail ainsi que tous les alias de cette adresse e-mail. Paramètres member : membre à évaluer. memberPrefixes : liste de chaînes à faire correspondre au début du nom du membre. Exemple Renvoie true si le membre member commence par user:prod- : MemberSubjectStartsWith(member, ['user:prod-'])
MemberSubjectEndsWith(   member,   memberSuffixes: list )   bool	Renvoie true si le membre member se termine par au moins l'une des chaînes listées dans memberSuffixes. Si l'identifiant de member est une adresse e-mail, cette fonction évalue l'adresse e-mail ainsi que tous les alias de cette adresse e-mail. Paramètres member : membre à évaluer. memberSuffixes : liste de chaînes à faire correspondre à la fin du nom du membre. Exemple Renvoie true si le membre member se termine par @example.com : MemberSubjectEndsWith(member, ['@example.com'])
MemberInPrincipalSet(   member,   principalSets: list )   bool	Renvoie true si le membre appartient à au moins l'un des ensembles de comptes principaux listés. Paramètres member : membre à évaluer. principalSets : liste d'ensembles de comptes principaux. Pour que la fonction soit évaluée sur true, le membre doit appartenir à au moins l'un de ces ensembles de comptes principaux. Le seul ensemble de comptes principaux accepté est l'ensemble de comptes principaux de l'organisation, qui se présente au format //cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID. Lorsqu'il est utilisé dans la fonction MemberInPrincipalSet, cet ensemble de comptes principaux inclut les comptes principaux suivants : 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 Tous les agents de service associés aux ressources de votre organisation. Exemple Renvoie true si le membre member appartient à l'organisation @example.com, dont l'ID est 123456789012 : MemberInPrincipalSet(member, ['//cloudresourcemanager.googleapis.com/organizations/123456789012'])
MemberTypeMatches(   member,   principalType: list )   bool	Renvoie true si le membre fait partie des types de principaux listés. Paramètres member : membre à évaluer. principalType : liste des types de comptes principaux. Pour que la fonction soit évaluée sur true, le membre doit être l'un des types de comptes principaux listés. Pour savoir quels types de comptes principaux sont acceptés, consultez Types de comptes principaux acceptés pour MemberTypeMatches. Exemple Renvoie true si le membre member a le type de principal iam.googleapis.com/WorkspacePrincipal ou iam.googleapis.com/WorkspaceGroup : MemberTypeMatches(member, ['iam.googleapis.com/WorkspacePrincipal', 'iam.googleapis.com/WorkspaceGroup'])

Macros pour évaluer les listes

Utilisez les macros all et exists pour évaluer une expression de condition pour une liste d'éléments.

Macro	Description
list.all(   item,   conditionExpression )   bool	Renvoie true si conditionExpression renvoie true pour chaque item dans list. Cette macro est généralement utilisée pour les règles d'administration personnalisées avec actionType ALLOW. Par exemple, vous pouvez utiliser cette macro pour vous assurer qu'une action n'est autorisée que si tous les comptes principaux modifiés remplissent la condition. Paramètres list : liste des éléments à évaluer. item : élément de liste à évaluer. Par exemple, si vous appelez cette méthode sur la liste resource.bindings, utilisez la valeur binding. conditionExpression : expression de condition à évaluer pour chaque item. Exemple Renvoie true si toutes les liaisons dans resource.bindings ont des rôles qui commencent par roles/storage.. Renvoie false si l'une des liaisons comporte des rôles qui ne commencent pas par roles/storage. : resource.bindings.all(binding, RoleNameStartsWith(binding.role, ['roles/storage.']))
list.exists(   item,   conditionExpression )   bool	Renvoie true si conditionExpression renvoie true pour n'importe quel item dans list. Cette macro est généralement utilisée pour les règles d'administration personnalisées avec actionType DENY. Par exemple, vous pouvez utiliser cette macro pour vous assurer qu'une action est refusée si l'un des comptes principaux modifiés remplit la condition. Paramètres list : liste des éléments à évaluer. item : élément de liste à évaluer. Par exemple, si vous appelez cette méthode sur la liste resource.bindings, utilisez la valeur binding. conditionExpression : expression de condition à évaluer pour chaque item. Exemple Renvoie true si l'une des liaisons dans resource.bindings comporte des rôles commençant par roles/storage.. Renvoie false si aucune des liaisons n'a de rôle commençant par roles/storage. : resource.bindings.exists(binding, RoleNameStartsWith(binding.role, ['roles/storage.']))

Conditions avec des listes imbriquées

En général, si votre condition inclut des listes imbriquées, vous devez utiliser la même macro pour toutes les listes de la condition.

Prenons les exemples suivants :

• Si votre règle comporte actionType ALLOW, utilisez la macro all pour les listes members et bindings afin de vous assurer que les modifications de la règle ne sont autorisées que si tous les membres de toutes les liaisons modifiées remplissent la condition.
• Si votre règle comporte les actionType DENY, utilisez la macro exists pour les listes members et bindings afin de vous assurer que les modifications de la règle ne sont pas autorisées si un membre d'une liaison modifiée satisfait la condition.

Si vous mélangez des macros dans une même condition, il est possible que celle-ci ne se comporte pas comme vous le souhaitez.

Par exemple, imaginons que vous souhaitiez empêcher l'attribution de rôles à des membres extérieurs à l'organisation example.com. L'organisation example.com a l'ID 123456789012.

Pour atteindre cet objectif, vous devez écrire la condition suivante :

Approche déconseillée : condition mal configurée

"resource.bindings.all(
  binding,
  binding.members.exists(member,
    MemberInPrincipalSet(member, ['//cloudresourcemanager.googleapis.com/organizations/123456789012'])
  )
)"

Cette condition semble empêcher l'attribution de rôles aux membres en dehors de l'organisation example.com. Toutefois, la condition renvoie true si un membre de chacune des liaisons de rôle modifiées se trouve dans l'organisation example.com. Par conséquent, vous pouvez toujours attribuer des rôles à des membres extérieurs à l'organisation example.com si vous attribuez également le même rôle à un membre de l'organisation example.com.

Par exemple, la condition renvoie true pour l'ensemble suivant de liaisons, même si l'un des membres ne fait pas partie de l'organisation example.com :

 "bindings": [
    {
      "members": [
        "user:[e-mail]",
        "user:[e-mail]"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],

Écrivez plutôt une condition comme celle-ci :

Recommandé : condition correctement configurée

"resource.bindings.all(
  binding,
  binding.members.all(member,
    MemberInPrincipalSet(member, ['//cloudresourcemanager.googleapis.com/organizations/123456789012'])
  )
)"

L'utilisation de la macro all pour le tableau members.bindings et le tableau resource.bindings garantit que la condition n'est évaluée sur true que si tous les membres de toutes les liaisons se trouvent dans l'ensemble de principaux example.com.

Types de comptes principaux acceptés pour MemberTypeMatches

La fonction MemberTypeMatches vous oblige à spécifier le type de compte principal auquel le membre spécifié doit correspondre.

Le tableau suivant liste les types de comptes principaux que vous pouvez saisir et décrit ce qu'ils représentent. Elle liste également les identifiants de compte principal qui correspondent à chaque type de compte principal. Ces identifiants sont les valeurs utilisées dans les stratégies IAM.

Type de compte principal	Description	Identifiants principaux
iam.googleapis.com/ConsumerPrincipal	Un compte Google personnel. Les adresses e-mail de ces comptes se terminent généralement par gmail.com.	user:USER_EMAIL_ADDRESS
iam.googleapis.com/WorkspacePrincipal	Un compte Google faisant partie d'un compte Cloud Identity ou Google Workspace. Ces comptes sont également appelés comptes utilisateur gérés.	user:USER_EMAIL_ADDRESS
iam.googleapis.com/ConsumerGroup	Un groupe Google créé par un compte Google grand public. Ces groupes n'appartiennent pas à un compte Cloud Identity ou Google Workspace. Les adresses e-mail de ces groupes se terminent généralement par googlegroups.com.	group:GROUP_EMAIL_ADDRESS
iam.googleapis.com/WorkspaceGroup	Un groupe Google appartenant à un compte Cloud Identity ou Google Workspace.	group:GROUP_EMAIL_ADDRESS
iam.googleapis.com/Domain	Un compte Cloud Identity ou Google Workspace	domain:DOMAIN
iam.googleapis.com/WorkforcePoolPrincipal	Entité principale unique dans un pool d'identités de personnel.	principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
iam.googleapis.com/WorkforcePoolPrincipalSet	Ensemble de comptes principaux contenant un ensemble d'identités dans un pool d'identités de personnel. Par exemple, un ensemble de comptes principaux contenant tous les comptes principaux d'un pool d'identités de personnel.	principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*
iam.googleapis.com/WorkloadPoolPrincipal	Une identité unique dans un pool d'identités de charge de travail	principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
iam.googleapis.com/WorkloadPoolPrincipalSet	Ensemble de comptes principaux contenant un ensemble d'identités dans un pool d'identités de charge de travail. Par exemple, un ensemble de comptes principaux contenant tous les comptes principaux d'un pool d'identités de charge de travail.	principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP_ID principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*
iam.googleapis.com/ServiceAccount	Tout compte de service. Un compte de service est un type de compte spécial qui représente une charge de travail plutôt qu'un utilisateur humain. Dans le contexte de la fonction MemberTypeMatches, ce type de compte principal n'inclut pas les agents de service.	serviceAccount:SERVICE_ACCOUNT_EMAIL_ADDRESS
iam.googleapis.com/ServiceAgent	Tout agent de service. Un agent de service est un type spécial de compte de service que Google Cloud crée et gère. Lorsqu'ils se voient attribuer des rôles dans vos projets, les agents de service permettent aux services Google Cloud d'effectuer des actions en votre nom.	serviceAccount:SERVICE_AGENT_EMAIL_ADDRESS
iam.googleapis.com/PublicPrincipals	Les comptes principaux allUsers et allAuthenticatedUsers.	allUsers allAuthenticatedUsers
iam.googleapis.com/ProjectRoleReference	Comptes principaux définis en fonction du rôle qui leur est attribué. Ces principaux sont également appelés valeurs pratiques.	projectOwner:PROJECT_ID projectEditor:PROJECT_ID projectViewer:PROJECT_ID
iam.googleapis.com/ResourcePrincipal	Ressource avec une identité intégrée.	N'importe quel identifiant principal listé dans Identifiants principaux pour les ressources uniques.
iam.googleapis.com/ResourcePrincipalSet	Ressources avec des identités intégrées qui partagent certaines caractéristiques, telles que le type ou l'ancêtre.	N'importe quel identifiant listé dans Identifiants principaux pour les ensembles de ressources.

Étapes suivantes

• Découvrez-en plus sur le service de règles d'administration.
• Découvrez comment créer et gérer des règles d'administration.
• Consultez la liste complète des contraintes liées aux règles d'administration gérées.