Stratégies de limite d'accès des comptes principaux

Les stratégies de limite d'accès des principaux (PAB, Principal Access Boundary) vous permettent de définir les ressources auxquelles les principaux peuvent accéder.

D'autres règles liées à l'accès, comme les stratégies d'autorisation et de refus, sont associées aux ressources. Ces stratégies définissent qui est autorisé à accéder à la ressource à laquelle elles sont associées. En revanche, les stratégies de limite d'accès des comptes principaux sont associées à des ensembles de comptes principaux et contrôlent ce que les comptes principaux de l'ensemble sont autorisés à faire.

Par exemple, vous pouvez utiliser des règles de limite d'accès des comptes principaux pour empêcher vos comptes principaux d'accéder aux ressources d'autres organisations. Cela peut vous aider à prévenir les attaques par hameçonnage ou l'exfiltration de données.

Fonctionnement des stratégies de limite d'accès des comptes principaux

Par défaut, les comptes principaux sont autorisés à accéder à n'importe quelle ressource Cloud de Confiance by S3NS . Cela signifie que si une stratégie d'autorisation accorde à un compte principal l'accès à une ressource et qu'aucune stratégie de refus ne bloque cet accès, le compte principal peut accéder à la ressource.

Les stratégies de limite d'accès des principaux vous permettent de définir les ressources auxquelles un principal est autorisé à accéder. Si un compte principal n'est pas autorisé à accéder à une ressource, son accès à cette ressource est limité, quels que soient les rôles qui lui ont été attribués. Pour en savoir plus sur l'utilisation des stratégies Limite d'accès des principaux afin de définir les ressources auxquelles un principal est autorisé à accéder, consultez Définir les ressources autorisées.

Les stratégies de limite d'accès des comptes principaux ne bloquent que les tentatives d'accès impliquant des autorisations compatibles. Si une stratégie de limite d'accès des comptes principaux ne peut pas bloquer une autorisation, les comptes principaux peuvent utiliser cette autorisation pour accéder à n'importe quelle ressource, quelles que soient les stratégies auxquelles ils sont soumis. Pour en savoir plus, consultez Autorisations que les stratégies de limite d'accès des principaux peuvent bloquer.

Cas d'utilisation

Les stratégies de limite d'accès des comptes principaux sont utiles dans les cas suivants :

• Empêcher les comptes principaux d'accéder aux ressources qui ne vous appartiennent pas
• Limiter certains types de comptes principaux, comme les comptes de service, à certains projets

Pour obtenir des exemples détaillés de la façon dont vous pouvez utiliser les stratégies de limite d'accès des comptes principaux dans de telles situations, consultez Exemples de cas d'utilisation des stratégies de limite d'accès des comptes principaux.

Composants de la stratégie de limite d'accès des comptes principaux

Les stratégies de limite d'accès des comptes principaux sont constituées de règles individuelles. Chaque règle définit un ensemble de ressources auxquelles les comptes principaux peuvent accéder. Chaque stratégie peut comporter jusqu'à 500 règles.

Les règles contiennent également d'autres informations, y compris des métadonnées et des détails de configuration. Pour en savoir plus, consultez Structure d'une stratégie de limite d'accès des comptes principaux.

Une fois que vous avez créé une stratégie de limite d'accès des comptes principaux, vous l'appliquez à des ensembles de comptes principaux en créant des liaisons de stratégie. Tous les comptes principaux de ces ensembles sont alors soumis à cette stratégie de limite d'accès des comptes principaux, ce qui signifie qu'ils peuvent accéder aux ressources listées dans la stratégie. Vous pouvez associer une stratégie de limite d'accès des comptes principaux à un nombre illimité d'ensembles de comptes principaux.

Vous pouvez créer jusqu'à 1 000 stratégies de limite d'accès des comptes principaux dans votre organisation.

Autorisations bloquées par les stratégies de limite d'accès des comptes principaux

Les stratégies de limite d'accès des comptes principaux peuvent bloquer toutes les autorisations incluses dans la version d'application de la stratégie. Si une règle de limite d'accès des comptes principaux peut bloquer une autorisation, elle peut empêcher les comptes principaux non éligibles d'utiliser cette autorisation pour accéder aux ressources.

Vous spécifiez la version d'application d'une règle lorsque vous la créez. La mise à jour de la version d'application met à jour les autorisations que la stratégie peut bloquer. Pour obtenir la liste complète des autorisations bloquées par chaque version d'application des règles, consultez la documentation de référence sur les versions d'application des règles.

Si une stratégie de limite d'accès des comptes principaux ne peut pas bloquer une autorisation, elle n'a aucun effet sur la capacité des comptes principaux à utiliser cette autorisation. En d'autres termes, IAM ne peut pas appliquer la stratégie pour les tentatives d'accès impliquant cette autorisation.

Par exemple, imaginons qu'un compte principal, Lee (lee@example.com), se voit attribuer le rôle Développeur Dataflow (roles/dataflow.developer). Ce rôle inclut l'autorisation dataflow.googleapis.com/jobs.snapshot, qui permet à Lee de créer des instantanés des jobs Dataflow. Lee est également soumis à une règle de limite d'accès des comptes principaux qui l'empêche d'accéder aux ressources en dehors de example.com. Toutefois, si cette règle de limite d'accès des comptes principaux ne peut pas bloquer l'autorisation dataflow.jobs.snapshot, Lee peut toujours prendre des instantanés des tâches Dataflow dans les organisations en dehors de example.com.

Gérer les versions des mesures d'application

De temps en temps, IAM ajoute de nouvelles versions d'application qui peuvent bloquer des autorisations supplémentaires. Chaque nouvelle version peut également bloquer toutes les autorisations de la version précédente.

Pour bloquer les autorisations dans une nouvelle version d'application, vous devez mettre à jour vos règles de limites d'accès aux comptes principaux afin d'utiliser la nouvelle version.

Si vous souhaitez que la version d'application d'une règle soit mise à jour automatiquement à mesure que de nouvelles versions sont publiées, vous pouvez utiliser la valeur latest lors de la création de la règle. Toutefois, nous vous déconseillons d'utiliser cette valeur, car elle peut entraîner la perte inattendue de l'accès aux ressources par les comptes principaux.

Les règles qui utilisent latest pour le numéro de version utilisent la version d'application par défaut. La version d'application par défaut est généralement la plus récente. Toutefois, il peut s'écouler jusqu'à quatre semaines avant qu'une nouvelle version ne devienne la version par défaut. Pour savoir quelle version d'application des règles est définie par défaut, consultez la documentation de référence sur les versions d'application des règles.

La version d'application par défaut est également utilisée pour les nouvelles règles de limites d'accès des comptes principaux qui ne spécifient pas de numéro de version.

Définir les ressources éligibles

Les comptes principaux peuvent être affectés par un nombre illimité de règles de limite d'accès des comptes principaux ou y être soumis. Ensemble, ces stratégies définissent les ressources auxquelles le principal est autorisé à accéder.

Les stratégies de limite d'accès des comptes principaux sont cumulatives. Cela signifie que les ressources auxquelles un principal est autorisé à accéder sont l'union de toutes les ressources de toutes les stratégies de limite d'accès des principaux auxquelles le principal est soumis. En d'autres termes, si une seule stratégie de limite d'accès des comptes principaux permet à un compte principal d'accéder à une ressource, il peut y accéder, quelles que soient les autres stratégies de limite d'accès des comptes principaux auxquelles il est soumis.

Si un compte principal n'est soumis à aucune stratégie de limite d'accès des comptes principaux, il peut accéder à n'importe quelle ressource Cloud de Confiance .

Les sections suivantes expliquent comment personnaliser l'ensemble des ressources auxquelles un principal peut accéder.

Ajouter des ressources éligibles

Il existe plusieurs façons de rendre un compte principal éligible à l'accès à une ressource à laquelle il n'est pas autorisé à accéder :

• Ajoutez la ressource à une stratégie de limite d'accès des comptes principaux à laquelle le compte principal est soumis.
• Créez une stratégie de limite d'accès des comptes principaux avec la ressource supplémentaire et associez la stratégie à un ensemble de comptes principaux qui inclut le compte principal.
• Supprimez toutes les stratégies de limite d'accès des comptes principaux auxquelles le compte principal est soumis. Cette action permet au compte principal d'accéder à toutes les ressources Cloud de Confiance .

Supprimer des ressources éligibles

Il existe plusieurs façons de rendre un compte principal non éligible à l'accès à une ressource à laquelle il est éligible.

Tout d'abord, recherchez toutes les stratégies de limite d'accès des comptes principaux auxquelles le compte principal est soumis et qui incluent la ressource. En fonction des règles que vous trouvez, vous pouvez ensuite effectuer l'une des actions suivantes :

• Si le compte principal n'est soumis à aucune stratégie de limite d'accès des comptes principaux, créez-en une qui ne contienne que les ressources auxquelles vous souhaitez que le compte principal puisse accéder. Ensuite, liez cette stratégie à un ensemble de comptes principaux contenant le compte principal.

  Une fois la stratégie appliquée, le compte principal passe d'un accès à toutes les ressources à un accès limité aux ressources listées dans la stratégie.

• Si le compte principal est déjà soumis à une ou plusieurs stratégies de limite d'accès, vous devez vous assurer qu'aucune des stratégies de limite d'accès auxquelles il est soumis n'inclut la ressource. Pour obtenir des instructions détaillées, consultez Réduire les ressources auxquelles les principaux peuvent accéder.

  Au cours de ce processus, vous devez vous assurer que le principal est toujours soumis à au moins une stratégie Limite d'accès des principaux. Sinon, le compte principal peut devenir éligible à l'accès à toutes les ressources.

Stratégies de limite d'accès des comptes principaux et ressources mises en cache

Certains services Cloud de Confiance by S3NS mettent en cache les ressources visibles publiquement. Par exemple, Cloud Storage met en cache les objets lisibles publiquement.

La possibilité pour une règle de limite d'accès des comptes principaux d'empêcher les comptes principaux non éligibles de consulter une ressource visible publiquement dépend de la mise en cache de la ressource :

• Si la ressource est mise en cache, les règles de limite d'accès des comptes principaux ne peuvent pas empêcher les comptes principaux de la consulter.
• Si la ressource n'est pas mise en cache, la limite d'accès des principaux empêche les principaux non éligibles de la consulter.

Dans tous les cas, les règles de limite d'accès des comptes principaux empêchent toujours les comptes principaux non éligibles de modifier ou de supprimer les ressources visibles publiquement.

Évaluation des stratégies de limite d'accès des comptes principaux

Lorsqu'un compte principal tente d'accéder à une ressource, IAM évalue les stratégies de limite d'accès des comptes principaux pertinentes pour déterminer s'il faut bloquer la tentative d'accès. Une stratégie est pertinente si le compte principal qui tente d'accéder à la ressource y est soumis.

Les stratégies de limite d'accès des comptes principaux ne peuvent que bloquer ou ne pas bloquer l'accès. Elles ne peuvent pas l'accorder. Seules les stratégies d'autorisation peuvent réellement accorder aux comptes principaux l'accès aux ressources. Pour savoir comment les différents types de règles affectent l'accès des principaux aux ressources, consultez Types de règles.

IAM n'empêche pas l'accès si l'une des conditions suivantes est remplie :

• Le compte principal n'est soumis à aucune stratégie de limite d'accès des comptes principaux.
• Les stratégies de limite d'accès des comptes principaux concernées ne peuvent pas bloquer l'autorisation dans la demande.
• Une stratégie de limite d'accès des comptes principaux permet au principal d'accéder à la ressource.

IAM bloque l'accès si le compte principal est soumis à au moins une stratégie de limite d'accès des comptes principaux, mais qu'aucune des stratégies pertinentes ne permet au compte principal d'accéder à la ressource.

Évaluation avec échec par défaut

Les stratégies de limite d'accès des comptes principaux sont fermées par défaut. Cela signifie que si IAM rencontre une erreur lors de l'évaluation d'une stratégie de limite d'accès des comptes principaux, il empêche le compte principal d'accéder à la ressource.

La raison la plus courante pour laquelle IAM rencontre une erreur lors de l'évaluation des stratégies de limite d'accès des comptes principaux est que les informations d'un compte principal sont toujours en cours de propagation dans le système. Cela se produit le plus souvent pour les utilisateurs nouvellement créés. Pour résoudre ce problème, demandez au nouveau principal d'attendre et de réessayer d'accéder à la ressource plus tard.

Appliquer des stratégies de limite d'accès des comptes principaux à des ensembles de comptes principaux

Pour appliquer une stratégie de limite d'accès des comptes principaux à un ensemble de comptes principaux, vous devez créer une liaison de stratégie qui spécifie à la fois la stratégie de limite d'accès des comptes principaux que vous souhaitez appliquer et l'ensemble de comptes principaux auquel vous souhaitez l'appliquer. Cette liaison de stratégie lie la stratégie à l'ensemble de comptes principaux.

Une fois que vous avez associé une stratégie à un ensemble de comptes principaux, les comptes principaux de cet ensemble ne peuvent accéder qu'aux ressources listées dans les stratégies de limite d'accès des comptes principaux auxquelles ils sont soumis.

Vous pouvez lier une stratégie de limite d'accès des comptes principaux à un nombre illimité d'ensembles de comptes principaux. Chaque ensemble de comptes principaux peut être associé à dix stratégies de limite d'accès des comptes principaux.

Vous ne pouvez créer des liaisons que pour les stratégies de limite d'accès des comptes principaux existantes. Toute tentative de création d'une liaison pour une stratégie de limite d'accès de compte principal supprimée échouera. Si vous avez récemment supprimé une stratégie Limite d'accès des principaux, vous pouvez parfois créer une liaison, mais celle-ci n'aura aucun effet. IAM supprime automatiquement ces liaisons.

Pour savoir comment gérer les stratégies de limite d'accès des comptes principaux, consultez Créer et appliquer des stratégies de limite d'accès des comptes principaux.

Ensembles de comptes principaux compatibles

Le tableau suivant liste les types d'ensembles de comptes principaux auxquels vous pouvez associer des règles de limite d'accès des comptes principaux. Chaque ligne contient les informations suivantes :

• Type d'ensemble de comptes principaux
• Comptes principaux de ce type d'ensemble de comptes principaux
• Format des ID pour ce type d'ensemble de comptes principaux
• Ressource Resource Manager (projet, dossier ou organisation) qui est le parent des liaisons de stratégie pour ce type d'ensemble de comptes principaux

Héritage des stratégies et ensembles de comptes principaux

Les stratégies de limite d'accès des comptes principaux sont associées à des ensembles de comptes principaux, et non à des ressources. Par conséquent, elles ne sont pas héritées via la hiérarchie des ressources de la même manière que les stratégies d'autorisation et de refus.

Toutefois, les ensembles de comptes principaux pour les dossiers et les organisations incluent toujours tous les comptes principaux dans les ensembles de comptes principaux de leurs descendants. Par exemple, si un compte principal est inclus dans l'ensemble de comptes principaux d'un projet, il est également inclus dans les ensembles de comptes principaux de tous les dossiers ou organisations parents.

Prenons l'exemple d'une organisation, example.com. Cette organisation est associée au domaine example.com et possède les ressources suivantes :

• Une organisation, example.com
• Un projet, project-1, qui est un enfant de l'organisation
• Dossier, folder-a, enfant de l'organisation
• Deux projets, project-2 et project-3, qui sont des enfants de folder-a

Les ensembles de comptes principaux de ces ressources contiennent les identités suivantes :

Par conséquent, les principaux suivants sont concernés par les stratégies de limite d'accès des comptes principaux suivantes :

• Une identité Google Workspace dans le domaine example.com se trouve dans l'ensemble de comptes principaux pour example.com et sera affectée par les règles de limite d'accès des comptes principaux liées à cet ensemble.

• Un compte de service dans project-1 se trouve dans les ensembles de comptes principaux pour project-1 et example.com. Il est donc affecté par les règles de limite d'accès des comptes principaux liées à l'un de ces ensembles.

• Une identité d'agent dans project-3 se trouve dans les ensembles de comptes principaux pour project-3, folder-a et example.com, et sera affectée par les règles de limite d'accès des comptes principaux liées à l'un de ces ensembles de comptes principaux.

Liaisons de stratégie conditionnelles pour les stratégies de limite d'accès des comptes principaux

Vous pouvez utiliser des expressions conditionnelles dans les liaisons de règles pour les stratégies de limite d'accès des comptes principaux afin de préciser les comptes principaux auxquels la règle s'applique.

Les expressions de condition pour les liaisons de règles se composent d'une ou plusieurs instructions combinées par un maximum de 10 opérateurs logiques (&&, || ou !). Chaque instruction exprime une règle de contrôle basée sur des attributs qui s'applique à la liaison de règle et détermine fondamentalement si la règle s'applique.

Vous pouvez utiliser les attributs principal.type et principal.subject dans les conditions des liaisons de règles. Aucun autre attribut n'est accepté.

• L'attribut principal.type fait référence au type de compte principal qui a effectué la requête (par exemple, un compte de service ou une identité d'agent). Vous pouvez utiliser des conditions avec cet attribut pour contrôler les types de comptes principaux auxquels s'applique une stratégie de limite d'accès des comptes principaux.

  Par exemple, si vous ajoutez l'expression de condition suivante à une liaison pour une règle de limite d'accès des comptes principaux, la règle ne s'applique qu'aux comptes de service :

  principal.type == 'iam.googleapis.com/ServiceAccount'
  

• L'attribut principal.subject fait référence à l'identité du compte principal qui a envoyé la requête, par exemple cruz@example.com. Vous pouvez utiliser des conditions avec cet attribut pour contrôler précisément les comptes principaux soumis à une stratégie de limite d'accès des comptes principaux.

  Par exemple, si vous ajoutez l'expression de condition suivante à une liaison pour une règle de limite d'accès des comptes principaux, la règle ne s'appliquera pas à l'utilisateur special-admin@example.com :

  principal.subject != 'special-admin@example.com'
  

Pour en savoir plus sur les valeurs que vous pouvez utiliser pour ces conditions, consultez la documentation de référence sur les attributs de conditions.

Pour obtenir un exemple d'utilisation de ces conditions dans vos règles de périmètre d'accès principal, consultez Rendre les comptes de service éligibles à l'accès aux ressources dans un seul projet.

Liaisons de stratégie inter-organisations

Vous ne pouvez pas créer de liaison de stratégie inter-organisation pour une stratégie de limite d'accès des comptes principaux. Une liaison de stratégie inter-organisation est une liaison de stratégie qui lie une stratégie dans une organisation à un ensemble de comptes principaux dans une autre organisation.

IAM supprime régulièrement les liaisons de stratégie inter-organisations existantes. Des liaisons de règles inter-organisations peuvent se produire lorsque vous déplacez un projet d'une organisation vers une autre. Prenons l'exemple suivant :

• Vous disposez d'un projet, example-project, dans l'organisation example.com.
• Vous souhaitez que les comptes principaux dans example-project puissent accéder aux ressources dans example.com. Pour ce faire, vous créez une stratégie de limite d'accès des comptes principaux dans example.com qui permet aux comptes principaux d'accéder aux ressources dans example.com et vous associez cette stratégie à l'ensemble de comptes principaux pour example-project.
• Vous déplacez example-project de example.com vers cymbalgroup.com.

Dans ce cas, le déplacement du projet crée une liaison de stratégie inter-organisations. En effet, la stratégie de limite d'accès des comptes principaux dans example.com est liée à un ensemble de comptes principaux dans cymbalgroup.com. Si vous ne supprimez pas l'association manuellement, IAM la supprimera automatiquement au bout d'un certain temps. La suppression de cette liaison permet de s'assurer que les administrateurs cymbalgroup.com ont accès à toutes les stratégies de limite d'accès des comptes principaux liées à leurs principaux.

Structure d'une stratégie Limite d'accès des principaux

Une stratégie de limite d'accès de compte principal est un ensemble de métadonnées et de détails de la stratégie de limite d'accès de compte principal. Les métadonnées fournissent des informations telles que le nom de la règle et la date de sa création. Les détails de la stratégie définissent son fonctionnement (par exemple, les ressources auxquelles les comptes principaux concernés peuvent accéder).

Par exemple, la stratégie Limite d'accès des principaux suivante permet aux principaux soumis à la stratégie d'accéder aux ressources de l'organisation dont l'ID est 0123456789012.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "4"
  }
}

Les sections suivantes décrivent les champs des métadonnées et des détails d'une stratégie de limite d'accès des principaux.

Métadonnées

Les stratégies de limite d'accès des comptes principaux contiennent les métadonnées suivantes :

• name : nom de la règle de limite d'accès des comptes principaux. Ce nom est au format organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, où ORGANIZATION_ID correspond à l'ID numérique de l'organisation dans laquelle la stratégie de limite d'accès des comptes principaux a été créée et PAB_POLICY_ID est l'ID alphanumérique de la stratégie de limite d'accès des comptes principaux.
• uid : ID unique attribué à la règle de limite d'accès des comptes principaux.
• etag : identifiant de l'état actuel de la règle. Cette valeur change lorsque vous mettez à jour la règle. Pour éviter les mises à jour en conflit, la valeur etag doit correspondre à la valeur stockée dans IAM. Si les valeurs etag ne correspondent pas, la requête échoue.
• displayName : nom lisible de la stratégie de limite d'accès des comptes principaux.
• annotations : facultatif. Liste de paires clé-valeur définies par l'utilisateur. Vous pouvez utiliser ces annotations pour ajouter des métadonnées à la stratégie, par exemple pour indiquer qui l'a créée ou si elle a été déployée par un pipeline automatisé. Pour en savoir plus sur les annotations, consultez Annotations.
• createTime : heure de création de la stratégie de limite d'accès des comptes principaux.
• updateTime : date et heure de la dernière mise à jour de la stratégie de limite d'accès des comptes principaux.

Détails

Chaque stratégie Limite d'accès des principaux contient un champ details. Ce champ contient les règles de limite d'accès des comptes principaux et la version d'application :

• rules : liste des règles de limite d'accès des principaux, qui définissent les ressources auxquelles les principaux concernés peuvent accéder. Chaque règle contient les champs suivants :

  • description : description du libellé dans un format lisible.

  • resources : liste des ressources Resource Manager (projets, dossiers et organisations) auxquelles vous souhaitez que les comptes principaux puissent accéder. Tout compte principal soumis à cette stratégie peut accéder à ces ressources.

    Chaque stratégie de limite d'accès des comptes principaux peut référencer au maximum 500 ressources pour l'ensemble des règles de la stratégie.

  • effect : relation entre les comptes principaux et les ressources répertoriées dans le champ resources. Le seul effet que vous pouvez spécifier dans les règles de limite d'accès des principaux est "ALLOW". Cette relation permet aux comptes principaux d'accéder aux ressources listées dans la règle.

• enforcementVersion : version d'application utilisée par IAM lors de l'application de la règle. La version de la stratégie de limite d'accès des comptes principaux détermine les autorisations que la stratégie de limite d'accès des comptes principaux peut bloquer.

  Pour savoir comment définir et gérer les versions d'application des règles, consultez Gérer les versions d'application des règles sur cette page.

Structure d'une liaison de stratégie

Une liaison de stratégie pour une stratégie de limite d'accès des comptes principaux contient le nom d'une stratégie, le nom de l'ensemble de comptes principaux auquel lier la stratégie et les métadonnées décrivant la liaison de stratégie. Elle peut également contenir des conditions qui modifient les administrateurs exacts auxquels la règle s'applique.

Par exemple, la liaison de règle suivante lie la règle example-policy à tous les comptes principaux de l'organisation example.com, qui possède l'ID 0123456789012. La liaison de stratégie contient également une condition qui empêche l'application de la stratégie pour le compte principal super-admin@example.com.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for super-admin@example.com",
    "expression": "principal.subject != 'super-admin@example.com'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

Chaque liaison de stratégie contient les champs suivants :

• name : nom de la liaison de stratégie. Ce nom est au format RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, où RESOURCE_TYPE/RESOURCE_ID correspond au type et à l'ID de la ressource parente de l'association de stratégie, et BINDING_ID est l'ID alphanumérique de l'association de stratégie.
• uid : ID unique attribué à la liaison de règle.
• etag : identifiant de l'état actuel de la règle. Cette valeur change lorsque vous mettez à jour la règle. Pour éviter les mises à jour en conflit, la valeur etag doit correspondre à la valeur stockée dans IAM. Si les valeurs etag ne correspondent pas, la requête échoue.
• displayName : nom lisible de l'association de règles.
• annotations : facultatif. Liste de paires clé-valeur définies par l'utilisateur. Vous pouvez utiliser ces annotations pour ajouter des métadonnées à la liaison de stratégie. Par exemple, vous pouvez indiquer qui a créé la liaison de stratégie ou si elle a été déployée par un pipeline automatisé. Pour en savoir plus sur les annotations, consultez Annotations.

• target : ensemble de comptes principaux auquel lier la stratégie. La valeur est au format {"principalSet": PRINCIPAL_SET}, où PRINCIPAL_SET est l'ID de l'ensemble de comptes principaux auquel vous souhaitez lier la règle.

  Chaque cible peut être associée à un maximum de 10 règles.

• policyKind : type de stratégie référencé par la liaison de stratégie. Pour les liaisons de stratégie des stratégies de limite d'accès des comptes principaux, cette valeur est toujours PRINCIPAL_ACCESS_BOUNDARY.

• policy : stratégie de limite d'accès des comptes principaux à lier à l'ensemble de comptes principaux cible.

• policyUid : ID unique attribué à la règle de limite d'accès des comptes principaux référencée dans le champ policy.

• condition : facultatif. Une expression logique qui affecte les comptes principaux pour lesquels IAM applique la stratégie. Si la condition renvoie "true" ou ne peut pas être évaluée, Identity and Access Management applique la stratégie au compte principal qui effectue la demande. Si la condition renvoie la valeur "false", Identity and Access Management n'applique pas la règle au principal. Pour en savoir plus, consultez Limite d'accès des principaux et conditions sur cette page.

• createTime : heure de création de la liaison de stratégie.

• updateTime : heure de la dernière mise à jour de l'association de stratégie.

Étapes suivantes

• En savoir plus sur les cas d'utilisation des stratégies de limite d'accès des comptes principaux
• Découvrez comment créer et appliquer des stratégies de limite d'accès des comptes principaux.
• Consultez les autorisations bloquées par chaque version d'application de la stratégie de limite d'accès des comptes principaux.