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 façon 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 voir ses rôles révoqués
  • 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 non-respects 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 :

  • 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 role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

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 :

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.

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

Console

Pour créer une contrainte personnalisée :

  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. Cliquez sur Contrainte personnalisée.
  4. Dans le champ Nom à afficher, saisissez un nom lisible pour la contrainte. Ce nom est utilisé dans les messages d'erreur et peut servir à l'identification et au débogage. N'utilisez pas d'informations permettant d'identifier personnellement l'utilisateur ni de données sensibles dans les noms à afficher, car ces informations pourraient être divulguées dans les messages d'erreur. Ce champ peut contenir jusqu'à 200 caractères.
  5. Dans la zone ID de contrainte, saisissez le nom souhaité pour votre nouvelle contrainte personnalisée. Une contrainte personnalisée ne peut contenir que des lettres (majuscules et minuscules) ou des chiffres, par exemple custom.disableGkeAutoUpgrade. Ce champ peut contenir jusqu'à 70 caractères, sans compter le préfixe (custom.), par exemple organizations/123456789/customConstraints/custom. N'incluez pas d'informations permettant d'identifier personnellement l'utilisateur ni de données sensibles dans l'ID de votre contrainte, car elles pourraient être divulguées dans les messages d'erreur.
  6. Dans la zone Description, saisissez une description lisible de la contrainte. Cette description est utilisée comme message d'erreur en cas de non-respect de la règle. Incluez des informations sur les raisons du non-respect des règles et sur la façon de le résoudre. Veuillez n'inclure aucune information permettant d'identifier l'utilisateur ou donnée sensible dans votre description, car ces informations pourraient être divulguées dans les messages d'erreur. Ce champ peut contenir jusqu'à 2 000 caractères.
  7. Dans la zone Type de ressource, sélectionnez le nom de la ressource REST Google Cloud contenant l'objet et le champ que vous souhaitez restreindre (par exemple, container.googleapis.com/NodePool). La plupart des types de ressources acceptent jusqu'à 20 contraintes personnalisées. Si vous essayez de créer d'autres contraintes personnalisées, l'opération échoue.
  8. Sous Méthode d'application, indiquez si vous souhaitez appliquer la contrainte sur une méthode REST CREATE ou sur les méthodes CREATE et UPDATE. Si vous appliquez la contrainte avec la méthode UPDATE sur une ressource qui ne la respecte pas, les modifications apportées à cette ressource sont bloquées par la règle d'administration, sauf si elles résolvent le cas de non-conformité.

    9. Les services Google Cloud ne sont pas tous compatibles avec les deux méthodes. Pour connaître les méthodes compatibles avec chaque service, recherchez le service dans la section Services compatibles.

  9. Pour définir une condition, cliquez sur Modifier la condition.
    1. Dans le panneau Ajouter une condition, créez une condition CEL faisant référence à une ressource de service acceptée, par exemple resource.management.autoUpgrade == false. Ce champ peut contenir jusqu'à 1 000 caractères. Pour en savoir plus sur l'utilisation du langage CEL, consultez Common Expression Language. Pour en savoir plus sur les ressources de service que vous pouvez utiliser dans vos contraintes personnalisées, consultez Services compatibles avec les contraintes personnalisées.
    2. Cliquez sur Enregistrer.
  10. Sous Action, indiquez si vous souhaitez autoriser ou refuser la méthode évaluée si la condition est remplie.

    11. L'action de refus signifie que l'opération de création ou de mise à jour de la ressource est bloquée si la condition renvoie la valeur "true".

    L'action "Autoriser" signifie que l'opération de création ou de mise à jour de la ressource n'est autorisée que si la condition renvoie la valeur "true". Tous les autres cas, à l'exception de ceux explicitement regroupés dans la condition, sont bloqués.

  11. Cliquez sur Créer une contrainte.

    12. Lorsque vous saisissez une valeur dans chaque champ, la configuration YAML équivalant à cette contrainte personnalisée s'affiche sur la droite.

gcloud

  1. Pour créer une contrainte personnalisée, créez un fichier YAML au format suivant : 
    2.       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 ne peut contenir que des lettres (majuscules et minuscules) ou des chiffres, par exemple custom.denyProjectIAMAdmin. Ce champ peut contenir jusqu'à 70 caractères.
    • RESOURCE_NAME : nom complet de la ressource Google Cloudcontenant 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 acceptée. Ce champ peut contenir jusqu'à 1 000 caractères. Par exemple, resource.bindings.exists(binding, RoleNameMatches(binding.role, ['roles/resourcemanager.projectIamAdmin'])).

      • Pour en savoir plus sur les ressources disponibles pour l'écriture de conditions, consultez la section Ressources compatibles.

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

      • L'action "Autoriser" signifie que si la condition renvoie la valeur "true", l'opération de création ou de mise à jour de la ressource est autorisée. Cela signifie également que tous les autres cas, à l'exception de celui explicitement regroupé dans la condition, sont bloqués.

      L'action de refus signifie que si la condition renvoie la valeur "true", l'opération de création ou de mise à jour de la ressource est bloquée.

    • DISPLAY_NAME : nom convivial de la contrainte. Ce champ peut contenir jusqu'à 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 peut contenir jusqu'à 2 000 caractères.
  2. 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'administration de votre organisation. Pour configurer une contrainte personnalisée, utilisez la commande gcloud org-policies set-custom-constraint : 
    3.         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 .

  3. Pour vérifier que la contrainte personnalisée existe, utilisez la commande gcloud org-policies list-custom-constraints : 
    4.       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 cette règle d'administration est appliquée ou non.
  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. Pour en savoir plus, consultez Tester les modifications apportées aux règles d'administration à l'aide de Policy Simulator.
  10. Pour appliquer la règle d'administration en mode de simulation, cliquez sur Définir la règle de dry run. Pour en savoir plus, consultez Créer une règle d'administration en mode simulation.
  11. Une fois que vous avez vérifié que la règle d'administration en mode simulation fonctionne comme prévu, définissez la règle active en cliquant sur Définir la règle.

gcloud

  1. 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 : 
    2.         name: projects/PROJECT_ID/policies/CONSTRAINT_NAME
        spec:
          rules:
          - enforce: true
        
        dryRunSpec:
          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.
  2. Pour appliquer la règle d'administration en mode dry run, exécutez la commande suivante avec l'indicateur dryRunSpec : 
    3.         gcloud org-policies set-policy POLICY_PATH \
          --update-mask=dryRunSpec

    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.

  3. Après avoir vérifié que la règle d'administration en mode simulation fonctionne comme prévu, définissez la règle active avec la commande org-policies set-policy et l'indicateur spec : 
    4.         gcloud org-policies set-policy POLICY_PATH \
          --update-mask=spec

    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 votre organisationGoogle Cloud .
    • 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 activée, attendez environ 15 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
Bloquez 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'autoriser 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 rosario@example.com : 

MemberSubjectMatches(member, ['user:rosario@example.com'])
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 à 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 est 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 tous les projets 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 règle générale, 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 les 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 la condition 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 remplit la condition.

Si vous mélangez des macros dans une même condition, il est possible que la condition ne se comporte pas comme prévu.

Par exemple, imaginons que vous souhaitiez empêcher l'attribution de rôles aux membres extérieurs à l'organisation example.com. L'organisation example.com porte 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 de liaisons suivant, même si l'un des membres ne fait pas partie de l'organisation example.com :

 "bindings": [
    {
      "members": [
        "user:raha@altostrat.com",
        "user:jie@example.com"
      ],
      "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 compatibles avec 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 des employés.
  • 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