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

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

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.

Pour en savoir plus sur les autres types de stratégies de contrôle des accès proposés par Identity and Access Management (IAM), consultez Types de stratégies.

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 Google Cloud . Cela signifie que si un compte principal dispose d'une autorisation sur la ressource et que cette autorisation ne lui est pas refusée, il peut l'utiliser pour accéder à la ressource.

Les stratégies de limite d'accès des comptes principaux vous permettent de définir les ressources auxquelles un compte principal est autorisé à accéder. Si une stratégie de limite d'accès des comptes principaux empêche un compte principal d'accéder à une ressource, son accès à cette ressource est limité, quels que soient les rôles qui lui ont été attribués.

Lorsque des comptes principaux tentent d'accéder à des ressources auxquelles ils ne sont pas autorisés, les stratégies de limite d'accès des comptes principaux peuvent bloquer certaines autorisations IAM (Identity and Access Management), mais pas toutes. Pour en savoir plus sur les autorisations bloquées, consultez Autorisations que la limite d'accès des comptes principaux peut bloquer.

Les stratégies de limite d'accès des comptes principaux sont composées de règles de limite d'accès des comptes principaux. Chaque règle de limite d'accès des comptes principaux définit un ensemble de ressources auxquelles les comptes principaux concernés peuvent accéder. Vous pouvez créer jusqu'à 1 000 stratégies de limite d'accès des comptes principaux dans votre organisation.

Une fois que vous avez créé une stratégie de limite d'accès des comptes principaux, vous créez une liaison de stratégie pour appliquer la stratégie à un ensemble de comptes principaux.

Un compte principal peut être soumis à une ou plusieurs stratégies de limite d'accès des comptes principaux. Chaque compte principal n'est autorisé à accéder qu'aux ressources listées dans ces règles. Pour toutes les autres ressources, l'accès du compte principal à cette ressource est limité, même si vous lui attribuez des rôles sur cette ressource.

Étant donné que les règles de limite d'accès des comptes principaux sont associées à des comptes principaux et non à des ressources, vous pouvez les utiliser pour empêcher les comptes principaux d'accéder aux ressources qui ne vous appartiennent pas. Prenons les exemples suivants :

• Le responsable Tal (tal@example.com) fait partie de l'organisation Google Workspace example.com.
• Tal se voit attribuer le rôle Administrateur de l'espace de stockage (roles/storage.admin) sur un bucket Cloud Storage dans une autre organisation, cymbalgroup.com. Ce rôle contient l'autorisation storage.objects.get, qui est nécessaire pour afficher les objets du bucket.
• Il n'existe aucune règle de refus dans cymbalgroup.com qui empêche Tal d'utiliser l'autorisation storage.objects.get.

Avec les stratégies d'autorisation et de refus uniquement, example.com ne peut pas empêcher Tal de consulter les objets de ce bucket externe. Aucun compte principal example.com n'est autorisé à modifier la règle d'autorisation du bucket. Il ne peut donc pas révoquer le rôle de Tal. Il n'est pas non plus autorisé à créer des règles de refus dans cymbalgroup.com. Il ne peut donc pas utiliser de règle de refus pour empêcher Tal d'accéder au bucket.

Toutefois, grâce aux stratégies de limites d'accès des comptes principaux, les administrateurs example.com peuvent s'assurer que Tal ne peut pas afficher les objets du bucket cymbalgroup.com ni d'aucun autre bucket en dehors de example.com. Pour ce faire, les administrateurs peuvent créer une stratégie de limite d'accès des comptes principaux indiquant que les comptes principaux example.com ne sont autorisés à accéder qu'aux ressources de example.com. Il peut ensuite créer une liaison de règle pour l'associer à tous les comptes principaux de l'organisation example.com. Avec une telle règle en place, Tal ne pourra pas afficher les objets du bucket cymbalgroup.com, même s'il dispose du rôle Administrateur de l'espace de stockage sur le bucket.

É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 ne peut pas évaluer une stratégie de limite d'accès des comptes principaux lors de l'évaluation de l'accès d'un compte principal, il empêche le compte principal d'accéder à la ressource.

La raison la plus courante pour laquelle IAM n'est pas en mesure d'évaluer les stratégies de limite d'accès des comptes principaux est que les détails 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 compte principal d'attendre et de réessayer d'accéder à la ressource ultérieurement.

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

Lorsque des comptes principaux tentent d'accéder à une ressource à laquelle ils ne sont pas autorisés, les stratégies de limite d'accès des comptes principaux les empêchent d'utiliser certaines autorisations IAM (Identity and Access Management) pour accéder à la ressource, mais pas toutes.

Si une stratégie de limite d'accès des comptes principaux bloque une autorisation, IAM applique les stratégies de limite d'accès des comptes principaux pour cette autorisation. En d'autres termes, elle empêche tout compte principal non autorisé à accéder à une ressource d'utiliser cette autorisation pour y accéder.

Si une stratégie de limite d'accès des comptes principaux ne bloque pas une autorisation, elle n'a aucun effet sur la capacité des comptes principaux à utiliser 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.jobs.snapshot, qui permet à Lee de prendre 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 les règles de limite d'accès des comptes principaux ne bloquent pas l'autorisation dataflow.jobs.snapshot, Lee peut toujours prendre des instantanés des tâches Dataflow dans les organisations en dehors de example.com.

Les autorisations bloquées par une stratégie de limite d'accès des comptes principaux dépendent de la version d'application de la limite d'accès des comptes principaux.

Versions d'application des limites d'accès des comptes principaux

Chaque stratégie de limite d'accès des comptes principaux spécifie une version d'application, qui identifie une liste prédéfinie d'autorisations IAM que la stratégie de limite d'accès des comptes principaux peut bloquer. Vous spécifiez la version d'application lorsque vous créez ou mettez à jour une stratégie de limite d'accès des comptes principaux. Si vous ne spécifiez pas de version d'application, IAM utilise la dernière version d'application et continuera à l'utiliser jusqu'à ce que vous la mettiez à jour.

De temps en temps, IAM ajoute de nouvelles versions d'application des limites d'accès des comptes principaux 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 es comptes principaux dafin d'utiliser la nouvelle version. Si vous souhaitez que la version d'application soit mise à jour automatiquement à mesure que de nouvelles versions sont publiées, vous pouvez utiliser la valeur latest lorsque vous créez 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.

Pour obtenir la liste complète des autorisations bloquées par chaque version d'application des règles, consultez Autorisations bloquées par les stratégies de limite d'accès des comptes principaux.

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

Pour lier 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 pour lequel vous souhaitez l'appliquer. Une fois que vous avez lié la stratégie à un ensemble de comptes principaux, les comptes principaux de cet ensemble ne peuvent accéder qu'aux ressources incluses dans les règles de la stratégie de limite d'accès des comptes principaux.

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 des comptes principaux supprimée échouera. Si vous avez récemment supprimé une stratégie de limite d'accès des comptes principaux, vous pouvez parfois créer une liaison, mais celle-ci n'aura aucun effet. IAM nettoie 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

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é dans les conditions pour les liaisons de stratégie.

• L'attribut principal.type indique le type d'entité de compte principal dans la requête (par exemple, les comptes de service ou les identités dans un pool d'identités de charge de travail). 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 indique l'identité du compte principal dans 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.

Exemple : utiliser des conditions pour réduire les ressources auxquelles un compte principal peut accéder

L'une des façons d'utiliser des conditions dans les liaisons de stratégie de limite d'accès des comptes principaux consiste à réduire les ressources auxquelles un seul compte principal est autorisé à accéder.

Imaginons que vous disposiez d'un compte de service, dev-project-service-account, avec l'adresse e-mail dev-project-service-account@dev-project.iam.gserviceaccount.com. Ce compte de service est soumis à une stratégie de limite d'accès des comptes principaux qui permet aux comptes principaux d'accéder à toutes les ressources de l'organisation example.com. Cette règle est associée à l'ensemble de comptes principaux de l'organisation example.com.

Vous décidez que dev-project-service-account ne doit pas pouvoir accéder à toutes les ressources de example.com, mais uniquement à celles de dev-project. En revanche, vous ne souhaitez pas modifier les ressources auxquelles les autres comptes principaux de l'ensemble de comptes principaux example.com peuvent accéder.

Pour effectuer cette modification, suivez la procédure permettant de réduire les ressources auxquelles les comptes principaux peuvent accéder, mais ajoutez une condition à la liaison de stratégie au lieu de la supprimer :

1. Vous confirmez que la seule stratégie de limite d'accès des comptes principaux à laquelle dev-project-service-account est soumis est celle qui permet aux comptes principaux d'accéder à toutes les ressources de example.com.

2. Vous créez une règle de limite d'accès des comptes principaux qui permet aux comptes principaux d'accéder aux ressources dans dev-project et l'associez à l'ensemble de comptes principaux pour dev-project. Vous utilisez la condition suivante dans la liaison de stratégie pour vous assurer que la stratégie n'est appliquée qu'à dev-project-service-account :

   "condition": {
     "title": "Only dev-project-service-account",
     "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.iam.gserviceaccount.com'"
   }
   

3. Vous exemptez dev-project-service-account de la stratégie de limite d'accès des comptes principaux qui permet aux comptes principaux d'accéder à toutes les ressources de example.com. Pour ce faire, ajoutez la condition suivante à la liaison de stratégie qui associe cette stratégie de limite d'accès des comptes principaux à l'ensemble de comptes principaux de l'organisation :

   "condition": {
     "title": "Exempt dev-project-service-account",
     "expression": "principal.subject != 'dev-project-service-account@dev-project.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
   }
   

   Pour savoir comment mettre à jour les stratégies de limite d'accès des comptes principaux existantes, consultez Modifier les stratégies de limite d'accès des comptes principaux.

Une fois cette condition ajoutée à la liaison de règle, dev-project-service-account n'est plus autorisé à accéder à toutes les ressources de example.com. Il n'est autorisé à accéder qu'aux ressources de dev-project.

Liaisons de règles 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 toutes 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 avez 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éerait une liaison de règle inter-organisations. En effet, la stratégie de limite d'accès des comptes principaux dans example.com serait liée à un ensemble de comptes principaux dans cymbalgroup.com. Si vous ne supprimez pas l'association manuellement, IAM finira par la supprimer automatiquement. 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 comptes principaux.

Interactions avec les règles

IAM évalue chaque stratégie de limite d'accès des comptes principaux en combinaison avec vos règles d'autorisation et de refus, ainsi qu'avec vos autres stratégies de limite d'accès des comptes principaux. Toutes ces stratégies permettent de déterminer si un compte principal peut accéder à une ressource.

Interaction avec d'autres types de règles

Lorsqu'un compte principal tente d'accéder à une ressource, IAM évalue toutes les stratégies de limite, d'autorisation et de refus d'accès des comptes principaux pertinentes pour vérifier si le compte principal est autorisé à accéder à la ressource. Si l'une de ces stratégies indique que le compte principal ne doit pas pouvoir accéder à la ressource, IAM l'empêche d'y accéder.

Par conséquent, si une stratégie de limite d'accès des comptes principaux empêche un compte principal d'accéder à une ressource, IAM l'empêche d'accéder à cette ressource, quelles que soient les stratégies d'autorisation et de refus associées à la ressource.

De plus, les stratégies de limite d'accès des comptes principaux ne donnent pas accès aux ressources. Bien que les stratégies de limite d'accès des comptes principaux puissent rendre un compte principal éligible à l'accès à une ressource, seules les stratégies d'autorisation peuvent réellement accorder au compte principal l'accès à la ressource.

Pour en savoir plus sur l'évaluation des stratégies IAM, consultez Évaluation des stratégies.

Interaction entre les stratégies de limite d'accès des comptes principaux

Si une stratégie de limite d'accès des comptes principaux permet à un compte principal d'accéder à une ressource, il pourra y accéder, quelles que soient les autres stratégies de limite d'accès des comptes principaux auxquelles il est soumis. Par conséquent, si un compte principal est déjà soumis à une stratégie de limite d'accès, vous ne pouvez pas ajouter d'autres stratégies de limite d'accès pour réduire son accès.

Par exemple, imaginons qu'un utilisateur, Dana (dana@example.com), soit soumis à une seule règle de limite d'accès des comptes principaux, prod-projects-policy. Cette règle permet aux comptes principaux d'accéder aux ressources dans prod-project. Dana est soumise à cette règle, car elle est liée à l'ensemble de comptes principaux de son organisation.

Vous allez créer une règle de limite d'accès des comptes principaux, dev-staging-projects-policy, qui permet aux comptes principaux d'accéder aux ressources dans dev-project et staging-project, puis la lier à l'ensemble de comptes principaux de l'organisation.

Grâce à ces règles de limite d'accès des comptes principaux, Dana peut accéder aux ressources dans dev-project, staging-project et prod-project.

Si vous souhaitez réduire les ressources auxquelles Dana est autorisé à accéder, vous devez modifier ou supprimer les stratégies de limite d'accès des comptes principaux auxquelles Dana est soumis.

Par exemple, vous pouvez modifier dev-staging-projects-policy afin que les comptes principaux ne puissent pas accéder aux ressources dans dev-project. Dana ne pourrait alors accéder qu'aux ressources de staging-project et prod-project.

Vous pouvez également supprimer prod-projects-policy en supprimant la liaison de stratégie qui l'associe à l'ensemble de comptes principaux de l'organisation. Dana ne pourrait alors accéder qu'aux ressources de dev-project et staging-project.

Toutefois, ces modifications n'affectent pas seulement Dana. Elles ont également une incidence sur les autres comptes principaux soumis aux liaisons et aux règles modifiées de limite d'accès des comptes principaux. Si vous souhaitez réduire les ressources auxquelles un seul compte principal est autorisé à accéder, utilisez des liaisons de stratégie conditionnelles.

Héritage des règles

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

Toutefois, les ensembles d'identités pour les ressources parentes de Resource Manager (dossiers et organisations) incluent toujours tous les comptes principaux dans les ensembles d'identités 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 comporte les ressources Resource Manager suivantes :

• Une organisation, example.com
• Un projet, project-1, qui est un enfant de l'organisation
• Un dossier, folder-a, qui est un 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 comptes 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. Elle est donc 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.

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

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

Certains services Google Cloud mettent en cache les ressources visibles publiquement. Par exemple, Cloud Storage met en cache les objets lisibles publiquement.

La possibilité pour une 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, la limite d'accès des comptes principaux ne peut pas empêcher les comptes principaux de la consulter.
• Si la ressource n'est pas mise en cache, la limite d'accès des comptes principaux empêche les comptes principaux non éligibles de la consulter.

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

Structure d'une stratégie de limite d'accès des comptes principaux

Une stratégie de limite d'accès des comptes principaux est un ensemble de métadonnées et de détails sur la stratégie de limite d'accès des comptes principaux. 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 de limite d'accès des comptes principaux suivante permet aux comptes 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": "1"
  }
}

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 comptes 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 règle de limite d'accès des comptes principaux.
• annotations : facultatif. Liste des paires clé-valeur définies par l'utilisateur. Vous pouvez utiliser ces annotations pour ajouter des métadonnées à la règle, 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 : heure à laquelle la stratégie de limite d'accès des comptes principaux a été mise à jour pour la dernière fois.

Détails

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

• rules : liste des règles de limite d'accès des comptes principaux, qui définissent les ressources auxquelles les comptes 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 à ce règlement 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 comptes 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 en savoir plus sur les versions des stratégies de limite d'accès des comptes principaux, consultez la section Versions d'application des limites d'accès des comptes principaux 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 la liaison de stratégie, et BINDING_ID est l'ID alphanumérique de la liaison de stratégie.
• uid : ID unique attribué à la liaison de stratégie.
• 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 stratégie.
• annotations : facultatif. Liste des 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 stratégies.

• policyKind : type de règle référencé par la liaison de règle. Pour les liaisons de stratégie pour les 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 compte principal. Pour en savoir plus, consultez la section Conditions et limites d'accès des comptes principaux 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.

Cas d'utilisation

Vous trouverez ci-dessous des situations courantes dans lesquelles vous pouvez utiliser des stratégies de limite d'accès des comptes principaux, ainsi que des exemples de stratégies de limite d'accès des comptes principaux et de liaisons de stratégies que vous pouvez créer dans chacune de ces situations. Pour savoir comment créer des stratégies de limite d'accès des comptes principaux et les associer à des ensembles de comptes principaux, consultez Créer et appliquer des stratégies de limite d'accès des comptes principaux.

Rendre les comptes principaux éligibles à l'accès aux ressources de votre organisation

Vous pouvez utiliser une stratégie de limite d'accès des comptes principaux pour permettre aux comptes principaux de votre organisation d'accéder aux ressources de votre organisation. Si c'est la seule stratégie de limite d'accès des comptes principaux à laquelle les comptes principaux de votre organisation sont soumis, elle les empêchera également d'accéder aux ressources en dehors de votre organisation.

Par exemple, imaginez que vous souhaitiez rendre tous les comptes principaux de l'organisation example.com éligibles à l'accès aux ressources de example.com et inéligibles à l'accès aux ressources d'autres organisations. Les comptes principaux de example.com incluent toutes les identités du domaine example.com, tous les pools d'identités de personnel de example.com, ainsi que tous les comptes de service et pools d'identités de charge de travail de n'importe quel projet de example.com.

Vous n'avez aucune stratégie de limite d'accès des comptes principaux qui s'applique à l'un des comptes principaux de votre organisation. Par conséquent, tous les comptes principaux peuvent accéder à toutes les ressources.

Pour permettre aux comptes principaux d'accéder aux ressources dans example.com et leur interdire d'accéder aux ressources en dehors de example.com, vous créez une règle de limite d'accès des comptes principaux qui permet aux comptes principaux d'accéder aux ressources dans example.com :

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Ensuite, vous créez une liaison de règle pour lier cette règle à l'ensemble de comptes principaux de l'organisation :

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

Lorsqu'elle est liée à l'ensemble de comptes principaux de l'organisation, cette stratégie permet à tous les comptes principaux de example.com d'accéder aux ressources de example.com. Comme il s'agit de la seule stratégie de limite d'accès des comptes principaux à laquelle ces comptes principaux sont soumis, elle empêche également les comptes principaux de example.com d'accéder aux ressources en dehors de votre organisation. Cela signifie qu'ils ne peuvent pas utiliser les autorisations bloquées par la règle de limite d'accès des comptes principaux pour accéder aux ressources en dehors de example.com, même s'ils disposent de ces autorisations pour ces ressources.

Rendre les comptes de service éligibles aux ressources d'un seul projet

Vous pouvez créer une stratégie de limite d'accès des comptes principaux pour permettre aux comptes de service d'un projet spécifique d'accéder aux ressources de ce projet.

Si cette stratégie est la seule limite d'accès des comptes principaux à laquelle les comptes de service sont soumis, ils ne pourront uniquement accéder aux ressources de ce projet.

Par exemple, imaginons que vous disposiez d'un projet, example-dev, dont le numéro est 901234567890. Vous souhaitez vous assurer que les comptes de service de example-dev ne peuvent accéder qu'aux ressources de example-dev.

Vous disposez d'une stratégie de limite d'accès des comptes principaux qui permet à tous les comptes principaux de votre organisation, y compris les comptes de service dans example-dev, d'accéder aux ressources dans example.com. Pour voir à quoi ressemble ce type de règle, consultez Rendre les comptes principaux éligibles à l'accès aux ressources de votre organisation.

Pour empêcher les comptes de service dans example-dev d'accéder aux ressources en dehors de example-dev, vous devez d'abord créer une règle de limite d'accès des comptes principaux qui permet aux comptes principaux d'accéder aux ressources dans example-dev.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Ensuite, vous créez une liaison de règle pour lier cette règle à tous les comptes principaux dans example-dev, puis vous ajoutez une condition pour que la liaison de règle ne s'applique qu'aux comptes de service :

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

Toutefois, cette stratégie ne modifie pas en soi les ressources auxquelles les comptes de service peuvent accéder. En effet, il existe déjà une stratégie de limite d'accès des comptes principaux qui permet à tous les comptes principaux de example.com d'accéder à toutes les ressources de example.com. Les règles de limite d'accès des comptes principaux sont cumulatives. Par conséquent, les comptes de service dans example-dev peuvent toujours accéder à toutes les ressources de example.com.

Pour vous assurer que les comptes de service de example-dev sont uniquement autorisés à accéder aux ressources de example-dev, vous devez ajouter une condition à la liaison de la stratégie de limite d'accès des comptes principaux existante pour empêcher son application aux comptes de service, y compris les comptes de service par défaut, dans example-dev :

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com') || !principal.subject == 'example-dev@appspot.gserviceaccount.com || !principal.subject == '901234567890-compute@developer.gserviceaccount.com'"
  }
}

Désormais, les comptes de service dans example-dev ne peuvent accéder qu'aux ressources de example-dev. Ils ne peuvent pas utiliser les autorisations bloquées par la règle de limite d'accès des comptes principaux pour accéder aux ressources en dehors de example-dev, même s'ils disposent de ces autorisations pour ces ressources.

Si vous souhaitez ensuite augmenter les ressources auxquelles ces comptes de service peuvent accéder, vous pouvez ajouter des ressources à la règle example-dev-only ou créer une règle de limite d'accès au principal supplémentaire et l'associer aux comptes de service.

Étapes suivantes

• 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 des stratégies de limite d'accès des comptes principaux.