Résoudre les problèmes liés aux autorisations IAM

Policy Troubleshooter vous aide à déterminer si un compte principal peut accéder à une ressource. À l'aide d'un compte principal, d'une ressource et d'une autorisation, Policy Troubleshooter examine les stratégies d'autorisation, les stratégies de refus et les stratégies de limite d'accès des comptes principaux (PAB, Principal Access Boundary) qui ont un impact sur l'accès du compte principal. Il vous indique ensuite si, en fonction de ces stratégies, le compte principal peut utiliser l'autorisation spécifiée pour accéder à la ressource. Il répertorie également les stratégies pertinentes et explique leur impact sur l'accès du compte principal.

Vous pouvez accéder à Policy Troubleshooter à l'aide de la consoleGoogle Cloud , de Google Cloud CLI ou de l'API REST. Pour les requêtes de base, la console Google Cloud est généralement plus rapide. Pour les scénarios plus complexes, envisagez plutôt gcloud CLI ou l'API REST.

Avant de commencer

  • Enable the Policy Troubleshooter API.

    Enable the API

Autorisations requises

Pour résoudre complètement les problèmes d'accès de vos comptes principaux, vous devez disposer des autorisations suivantes.

Autorisations permettant de résoudre les problèmes d'accès pour les comptes principaux individuels

Policy Troubleshooter analyse l'accès d'un compte principal à une ressource en fonction des stratégies d'autorisation, des stratégies de refus, des stratégies de limite d'accès des comptes principaux et des rôles que vous êtes autorisé à consulter. Si vous ne disposez pas des autorisations nécessaires pour afficher une stratégie s'appliquant à une ressource, ou si vous n'êtes pas autorisé à afficher un rôle personnalisé, il est possible que vous ne puissiez pas déterminer si un compte principal dispose d'un accès.

Autorisations permettant de résoudre les problèmes liés aux stratégies d'autorisation et de refus

Pour résoudre les problèmes liés aux stratégies d'autorisation et de refus, vous devez disposer d'autorisations sur l'organisation qui contient la ressource pour laquelle vous souhaitez résoudre les problèmes. Ces autorisations vous permettent d'afficher les stratégies d'autorisation et de refus qui contrôlent l'accès à la ressource.

Pour obtenir les autorisations nécessaires pour résoudre les problèmes d'accès d'un compte principal, demandez à votre administrateur de vous attribuer les rôles IAM suivants sur l'organisation contenant la ressource pour laquelle vous souhaitez résoudre les problèmes d'accès :

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

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

Si vous ne disposez pas des autorisations nécessaires pour afficher les règles d'autorisation et de refus d'une ressource, les résultats d'accès pour ces règles sont Unknown.

Autorisations permettant de résoudre les problèmes liés aux stratégies de limite d'accès des comptes principaux

Pour résoudre les problèmes liés aux stratégies de limite d'accès des comptes principaux, vous devez disposer d'autorisations sur l'organisation dont l'ensemble de comptes principaux inclut le compte principal. La façon dont vous identifiez cette organisation dépend du type de compte principal :

  • Comptes et groupes Google : organisation associée au domaine Google Workspace qui inclut le principal
  • Identités fédérées (identités dans les pools d'identités de personnel ou les pools d'identités de charge de travail) : organisation contenant le pool d'identités qui inclut le compte principal
  • Comptes de service : organisation contenant le projet dans lequel le compte de service a été créé

Ces autorisations vous permettent d'afficher les stratégies de limite d'accès des comptes principaux qui contrôlent les ressources auxquelles le compte principal peut accéder.

Pour obtenir les autorisations nécessaires pour résoudre les problèmes d'accès d'un compte principal, demandez à votre administrateur de vous attribuer les rôles IAM suivants sur l'organisation appropriée :

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

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

Si vous n'êtes pas autorisé à afficher les stratégies de limite d'accès des comptes principaux qui s'appliquent à un compte principal, les résultats d'accès pour ces stratégies sont Unknown.

Autorisations permettant de résoudre les problèmes d'accès des membres du groupe

Si vos stratégies d'autorisation et de refus incluent des groupes, vous devez disposer de l'autorisation groups.read de l'API Google Workspace Admin pour résoudre les problèmes d'accès pour des membres de groupe individuels. Les super-administrateurs et les administrateurs de groupe disposent automatiquement de cette autorisation. Pour accorder cette autorisation à un utilisateur autre que le super-administrateur ou l'administrateur de groupe, créez un rôle d'administrateur Google Workspace personnalisé contenant le droit groups.read (situé sous Droits pour l'API Admin) et attribuez-le à l'utilisateur.

Si vous ne disposez pas de ces autorisations, les liaisons de rôles et les règles de refus qui contiennent des groupes ou des domaines affichent le résultat d'accès Inconnu, sauf si la liaison de rôle ou la règle de refus inclut également explicitement le compte principal.

Autorisations permettant de résoudre les problèmes d'accès pour les membres du domaine

Si vos règles d'autorisation et de refus incluent un compte Google Workspace ou un domaine Cloud Identity, vous devez être administrateur du domaine pour résoudre les problèmes d'accès pour les membres individuels du domaine.

Si vous ne disposez pas de ces autorisations, les liaisons de rôles et les règles de refus qui contiennent des groupes ou des domaines affichent le résultat d'accès Inconnu, sauf si la liaison de rôle ou la règle de refus inclut également explicitement le compte principal.

Résoudre les problèmes d'accès

Pour résoudre les problèmes d'accès, vous devez disposer des informations suivantes :

  • Principale : l'adresse e-mail à vérifier. L'adresse e-mail doit faire référence à un utilisateur ou un compte de service. Les autres types de comptes principaux, y compris les groupes, les domaines, les identités de personnel et les identités de charge de travail, ne sont pas compatibles.
  • Ressource : le nom complet de la ressource pour laquelle vous souhaitez résoudre les problèmes d'accès. Par exemple, pour résoudre les problèmes d'accès au projet my-project, saisissez //cloudresourcemanager.googleapis.com/projects/my-project. Pour les autres types de ressources, consultez les exemples de noms de ressources complets.

  • Autorisation : l'autorisation pour la vérification. Si vous utilisez la consoleGoogle Cloud , la liste des suggestions s'affiche au fur et à mesure de la saisie.

    Pour résoudre un problème d'autorisation, celle-ci doit s'appliquer à la ressource de la demande. En d'autres termes, il doit être possible d'utiliser cette autorisation pour accéder à la ressource d'une manière ou d'une autre. Si l'autorisation ne s'applique pas à la ressource, la requête échoue. Par exemple, si vous essayez de résoudre les problèmes liés à l'autorisation compute.instances.get pour un cluster Google Kubernetes Engine, la requête échoue, car l'autorisation compute.instance.get ne peut pas être utilisée pour accéder aux clusters Google Kubernetes Engine.

    Pour obtenir la liste complète des autorisations, consultez la documentation de référence sur les autorisations.

Console

Pour résoudre les problèmes d'accès, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Policy Troubleshooter.

    Accéder à Policy Troubleshooter

  2. Saisissez l'adresse e-mail du compte principal dont vous souhaitez vérifier l'accès.

  3. Saisissez le nom de ressource complet de la ressource à vérifier.

    Si vous ne connaissez pas le nom complet de la ressource, procédez de l'une des manières suivantes :

    • Si vous résolvez des problèmes d'accès à un projet, un dossier ou une organisation, commencez à saisir du texte pour afficher les options de saisie semi-automatique.
    • Si vous résolvez des problèmes d'accès pour un autre type de ressource, cliquez sur Parcourir pour ouvrir la boîte de dialogue de recherche de ressources, puis recherchez la ressource :

      1. Dans la zone Sélectionner le champ d'application, sélectionnez un projet, un dossier ou une organisation dans lesquels effectuer la recherche.
      2. Dans la zone Type de ressource, sélectionnez les types de ressources que vous souhaitez rechercher.
      3. Dans le champ Rechercher des ressources, saisissez une partie du nom de la ressource.
      4. Dans la section des résultats, sélectionnez la ressource que vous souhaitez vérifier.
      5. Cliquez sur Sélectionner pour choisir la ressource et fermer la boîte de dialogue.
  4. Saisissez l'autorisation à vérifier.

    Si vous ne connaissez pas le nom complet de l'autorisation, commencez à le saisir pour afficher les options de saisie semi-automatique.

  5. Facultatif : pour vérifier plusieurs ressources et autorisations, sélectionnez Ajouter une autre paire et répétez l'étape précédente.

  6. Cliquez sur Vérifier l'accès.

gcloud

Pour savoir pourquoi un compte principal dispose ou non d'une autorisation IAM, utilisez la commande gcloud beta policy-troubleshoot iam.

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

  • VERSION : facultatif. Version de la commande à utiliser. Pour résoudre les problèmes d'accès basés uniquement sur les règles d'autorisation et de refus, ne spécifiez pas de version. Pour résoudre les problèmes d'accès basés sur les stratégies d'autorisation, de refus et de limite d'accès des comptes principaux, utilisez la version beta.
  • EMAIL : adresse e-mail du compte principal dont vous souhaitez résoudre les problèmes d'autorisation.
  • RESOURCE : ressource pour laquelle l'autorisation est accordée.
  • PERMISSION : autorisation dont vous souhaitez résoudre les problèmes.

Exécutez la commande gcloud beta policy-troubleshoot iam :

Linux, macOS ou Cloud Shell

gcloud VERSION policy-intelligence troubleshoot-policy iam RESOURCE --principal-email=EMAIL \
    --permission=PERMISSION

Windows (PowerShell)

gcloud VERSION policy-intelligence troubleshoot-policy iam RESOURCE --principal-email=EMAIL `
    --permission=PERMISSION

Windows (cmd.exe)

gcloud VERSION policy-intelligence troubleshoot-policy iam RESOURCE --principal-email=EMAIL ^
    --permission=PERMISSION

Vous devriez obtenir un résultat semblable à celui-ci :

Réponse

{
  "accessTuple": {
    "conditionContext": {
      "destination": {},
      "effectiveTags": [
        {
          "namespacedTagKey": "project-1/tag-key-1",
          "namespacedTagValue": "project-1/tag-key-1/tag-value-1",
          "tagKey": "tagKeys/123456789012",
          "tagKeyParentName": "projects/123456789012",
          "tagValue": "tagValues/123456789012"
        },
      ],
      "request": {},
      "resource": {}
    },
    "fullResourceName": "//cloudresourcemanager.googleapis.com/projects/project-1",
    "permission": "bigtable.instances.create",
    "permissionFqdn": "bigtable.googleapis.com/instances.create",
    "principal": "service-account-3@project-1.iam.gserviceaccount.com"
  },
  "allowPolicyExplanation": {
    "allowAccessState": "ALLOW_ACCESS_STATE_NOT_GRANTED",
    "explainedPolicies": [
      {
        "allowAccessState": "ALLOW_ACCESS_STATE_NOT_GRANTED",
        "bindingExplanations": [
          {
            "allowAccessState": "ALLOW_ACCESS_STATE_NOT_GRANTED",
            "combinedMembership": {
              "membership": "MEMBERSHIP_NOT_MATCHED",
              "relevance": "HEURISTIC_RELEVANCE_NORMAL"
            },
            "condition": {
              "expression": "resource.type == \"cloudresourcemanager.googleapis.com/Project\"",
              "title": "Resource-based condition"
            },
            "conditionExplanation": {
              "evaluationStates": [
                {
                  "end": 62,
                  "value": false
                }
              ],
              "value": false
            },
            "memberships": {
              "serviceAccount:service-account-1@project-1.iam.gserviceaccount.com": {
                "membership": "MEMBERSHIP_NOT_MATCHED",
                "relevance": "HEURISTIC_RELEVANCE_NORMAL"
              }
            },
            "relevance": "HEURISTIC_RELEVANCE_NORMAL",
            "role": "roles/bigquery.admin",
            "rolePermission": "ROLE_PERMISSION_NOT_INCLUDED",
            "rolePermissionRelevance": "HEURISTIC_RELEVANCE_NORMAL"
          },
          {
            "allowAccessState": "ALLOW_ACCESS_STATE_NOT_GRANTED",
            "combinedMembership": {
              "membership": "MEMBERSHIP_NOT_MATCHED",
              "relevance": "HEURISTIC_RELEVANCE_NORMAL"
            },
            "condition": {
              "expression": "resource.matchTag(\"project-1/tag-key-1\", \"tag-value-1\")",
              "title": "Tag-based condition"
            },
            "conditionExplanation": {
              "evaluationStates": [
                {
                  "end": 73,
                  "value": true
                }
              ],
              "value": true
            },
            "memberships": {
              "serviceAccount:service-account-2@project-1.iam.gserviceaccount.com": {
                "membership": "MEMBERSHIP_NOT_MATCHED",
                "relevance": "HEURISTIC_RELEVANCE_NORMAL"
              }
            },
            "relevance": "HEURISTIC_RELEVANCE_NORMAL",
            "role": "roles/bigquery.admin",
            "rolePermission": "ROLE_PERMISSION_NOT_INCLUDED",
            "rolePermissionRelevance": "HEURISTIC_RELEVANCE_NORMAL"
          },
          {
            "allowAccessState": "ALLOW_ACCESS_STATE_NOT_GRANTED",
            "combinedMembership": {
              "membership": "MEMBERSHIP_NOT_MATCHED",
              "relevance": "HEURISTIC_RELEVANCE_NORMAL"
            },
            "memberships": {
              "user:user-2@example.com": {
                "membership": "MEMBERSHIP_NOT_MATCHED",
                "relevance": "HEURISTIC_RELEVANCE_NORMAL"
              }
            },
            "relevance": "HEURISTIC_RELEVANCE_NORMAL",
            "role": "roles/compute.admin",
            "rolePermission": "ROLE_PERMISSION_NOT_INCLUDED",
            "rolePermissionRelevance": "HEURISTIC_RELEVANCE_NORMAL"
          },
          {
            "allowAccessState": "ALLOW_ACCESS_STATE_NOT_GRANTED",
            "combinedMembership": {
              "membership": "MEMBERSHIP_NOT_MATCHED",
              "relevance": "HEURISTIC_RELEVANCE_NORMAL"
            },
            "memberships": {
              "user:user-1@example.com": {
                "membership": "MEMBERSHIP_NOT_MATCHED",
                "relevance": "HEURISTIC_RELEVANCE_NORMAL"
              },
              "user:user-3@example.com": {
                "membership": "MEMBERSHIP_NOT_MATCHED",
                "relevance": "HEURISTIC_RELEVANCE_NORMAL"
              }
            },
            "relevance": "HEURISTIC_RELEVANCE_NORMAL",
            "role": "roles/iam.serviceAccountTokenCreator",
            "rolePermission": "ROLE_PERMISSION_NOT_INCLUDED",
            "rolePermissionRelevance": "HEURISTIC_RELEVANCE_NORMAL"
          },
          {
            "allowAccessState": "ALLOW_ACCESS_STATE_NOT_GRANTED",
            "combinedMembership": {
              "membership": "MEMBERSHIP_NOT_MATCHED",
              "relevance": "HEURISTIC_RELEVANCE_NORMAL"
            },
            "memberships": {
              "user:user-2@example.com": {
                "membership": "MEMBERSHIP_NOT_MATCHED",
                "relevance": "HEURISTIC_RELEVANCE_NORMAL"
              },
              "user:user-1@example.com": {
                "membership": "MEMBERSHIP_NOT_MATCHED",
                "relevance": "HEURISTIC_RELEVANCE_NORMAL"
              }
            },
            "relevance": "HEURISTIC_RELEVANCE_HIGH",
            "role": "roles/owner",
            "rolePermission": "ROLE_PERMISSION_INCLUDED",
            "rolePermissionRelevance": "HEURISTIC_RELEVANCE_HIGH"
          },
          {
            "allowAccessState": "ALLOW_ACCESS_STATE_NOT_GRANTED",
            "combinedMembership": {
              "membership": "MEMBERSHIP_MATCHED",
              "relevance": "HEURISTIC_RELEVANCE_NORMAL"
            },
            "memberships": {
              "serviceAccount:service-account-3@project-1.iam.gserviceaccount.com": {
                "membership": "MEMBERSHIP_MATCHED",
                "relevance": "HEURISTIC_RELEVANCE_NORMAL"
              },
              "serviceAccount:service-account-4@project-1.iam.gserviceaccount.com": {
                "membership": "MEMBERSHIP_NOT_MATCHED",
                "relevance": "HEURISTIC_RELEVANCE_NORMAL"
              }
            },
            "relevance": "HEURISTIC_RELEVANCE_NORMAL",
            "role": "roles/resourcemanager.projectIamAdmin",
            "rolePermission": "ROLE_PERMISSION_NOT_INCLUDED",
            "rolePermissionRelevance": "HEURISTIC_RELEVANCE_NORMAL"
          },
          {
            "allowAccessState": "ALLOW_ACCESS_STATE_NOT_GRANTED",
            "combinedMembership": {
              "membership": "MEMBERSHIP_NOT_MATCHED",
              "relevance": "HEURISTIC_RELEVANCE_NORMAL"
            },
            "memberships": {
              "serviceAccount:service-account-4@project-1.iam.gserviceaccount.com": {
                "membership": "MEMBERSHIP_NOT_MATCHED",
                "relevance": "HEURISTIC_RELEVANCE_NORMAL"
              }
            },
            "relevance": "HEURISTIC_RELEVANCE_NORMAL",
            "role": "roles/resourcemanager.tagViewer",
            "rolePermission": "ROLE_PERMISSION_NOT_INCLUDED",
            "rolePermissionRelevance": "HEURISTIC_RELEVANCE_NORMAL"
          }
        ],
        "fullResourceName": "//cloudresourcemanager.googleapis.com/projects/project-1",
        "policy": {
          "bindings": [
            {
              "condition": {
                "expression": "resource.type == \"cloudresourcemanager.googleapis.com/Project\"",
                "title": "Resource-based condition"
              },
              "members": [
                "serviceAccount:service-account-1@project-1.iam.gserviceaccount.com"
              ],
              "role": "roles/bigquery.admin"
            },
            {
              "condition": {
                "expression": "resource.matchTag(\"project-1/tag-key-1\", \"tag-value-1\")",
                "title": "Tag-based condition"
              },
              "members": [
                "serviceAccount:service-account-2@project-1.iam.gserviceaccount.com"
              ],
              "role": "roles/bigquery.admin"
            },
            {
              "members": [
                "user:user-2@example.com"
              ],
              "role": "roles/compute.admin"
            },
            {
              "members": [
                "user:user-1@example.com",
                "user:user-3@example.com"
              ],
              "role": "roles/iam.serviceAccountTokenCreator"
            },
            {
              "members": [
                "user:user-2@example.com",
                "user:user-1@example.com"
              ],
              "role": "roles/owner"
            },
            {
              "members": [
                "serviceAccount:service-account-3@project-1.iam.gserviceaccount.com",
                "serviceAccount:service-account-4@project-1.iam.gserviceaccount.com"
              ],
              "role": "roles/resourcemanager.projectIamAdmin"
            },
            {
              "members": [
                "serviceAccount:service-account-4@project-1.iam.gserviceaccount.com"
              ],
              "role": "roles/resourcemanager.tagViewer"
            }
          ],
          "etag": "BwYY6ttEMEY=",
          "version": 3
        },
        "relevance": "HEURISTIC_RELEVANCE_HIGH"
      },
    ],
    "relevance": "HEURISTIC_RELEVANCE_HIGH"
  },
  "denyPolicyExplanation": {
    "denyAccessState": "DENY_ACCESS_STATE_NOT_DENIED",
    "explainedResources": [
      {
        "denyAccessState": "DENY_ACCESS_STATE_NOT_DENIED",
        "explainedPolicies": [
          {
            "denyAccessState": "DENY_ACCESS_STATE_NOT_DENIED",
            "policy": {
              "createTime": "2024-04-09T23:28:24.103203Z",
              "displayName": "Troubleshooter v3 prober non-tag deny policy",
              "etag": "MTgyMzk3MDY4OTY4MDE0ODg4OTY=",
              "kind": "DenyPolicy",
              "name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F546942305807/denypolicies/deny-policy-1",
              "rules": [
                {
                  "denyRule": {
                    "deniedPermissions": [
                      "bigquery.googleapis.com/datasets.create"
                    ],
                    "deniedPrincipals": [
                      "principal://iam.googleapis.com/projects/-/serviceAccounts/service-account-1@project-1.iam.gserviceaccount.com"
                    ]
                  }
                }
              ],
              "uid": "fab63b4d-ecfb-5f06-8a6d-602bf1be5062",
              "updateTime": "2024-05-20T23:29:38.428095Z"
            },
            "relevance": "HEURISTIC_RELEVANCE_HIGH",
            "ruleExplanations": [
              {
                "combinedDeniedPermission": {
                  "permissionMatchingState": "PERMISSION_PATTERN_NOT_MATCHED",
                  "relevance": "HEURISTIC_RELEVANCE_HIGH"
                },
                "combinedDeniedPrincipal": {
                  "membership": "MEMBERSHIP_NOT_MATCHED",
                  "relevance": "HEURISTIC_RELEVANCE_HIGH"
                },
                "combinedExceptionPermission": {
                  "permissionMatchingState": "PERMISSION_PATTERN_NOT_MATCHED",
                  "relevance": "HEURISTIC_RELEVANCE_NORMAL"
                },
                "combinedExceptionPrincipal": {
                  "membership": "MEMBERSHIP_NOT_MATCHED",
                  "relevance": "HEURISTIC_RELEVANCE_NORMAL"
                },
                "deniedPermissions": {
                  "bigquery.googleapis.com/datasets.create": {
                    "permissionMatchingState": "PERMISSION_PATTERN_NOT_MATCHED",
                    "relevance": "HEURISTIC_RELEVANCE_HIGH"
                  }
                },
                "deniedPrincipals": {
                  "principal://iam.googleapis.com/projects/-/serviceAccounts/service-account-1@project-1.iam.gserviceaccount.com": {
                    "membership": "MEMBERSHIP_NOT_MATCHED",
                    "relevance": "HEURISTIC_RELEVANCE_HIGH"
                  }
                },
                "denyAccessState": "DENY_ACCESS_STATE_NOT_DENIED",
                "relevance": "HEURISTIC_RELEVANCE_HIGH"
              }
            ]
          },
        ],
        "fullResourceName": "//cloudresourcemanager.googleapis.com/projects/123456789012",
        "relevance": "HEURISTIC_RELEVANCE_HIGH"
      }
    ],
    "permissionDeniable": true,
    "relevance": "HEURISTIC_RELEVANCE_NORMAL"
  },
  "overallAccessState": "CANNOT_ACCESS",
  "pabPolicyExplanation": {
    "explainedBindingsAndPolicies": [
      {
        "bindingAndPolicyAccessState": "PAB_ACCESS_STATE_NOT_ENFORCED",
        "explainedPolicy": {
          "explainedRules": [
            {
              "combinedResourceInclusionState": "RESOURCE_INCLUSION_STATE_NOT_INCLUDED",
              "effect": "ALLOW",
              "explainedResources": [
                {
                  "relevance": "HEURISTIC_RELEVANCE_NORMAL",
                  "resource": "//cloudresourcemanager.googleapis.com/projects/project-2",
                  "resourceInclusionState": "RESOURCE_INCLUSION_STATE_NOT_INCLUDED"
                }
              ],
              "relevance": "HEURISTIC_RELEVANCE_NORMAL",
              "ruleAccessState": "PAB_ACCESS_STATE_NOT_ALLOWED"
            }
          ],
          "policy": {
            "createTime": "2024-04-09T17:40:51.627668Z",
            "details": {
              "enforcementVersion": "1",
              "rules": [
                {
                  "effect": "ALLOW",
                  "resources": [
                    "//cloudresourcemanager.googleapis.com/projects/project-2"
                  ]
                }
              ]
            },
            "displayName": "Troubleshooter v3 PAB Policy",
            "etag": "m64s4IgR80eDJDywuVA2DA==",
            "name": "organizations/123456789012/locations/global/principalAccessBoundaryPolicies/example-pab-policy",
            "uid": "puid_11875429267422576641",
            "updateTime": "2024-04-09T17:40:51.627668Z"
          },
          "policyAccessState": "PAB_ACCESS_STATE_NOT_ENFORCED",
          "policyVersion": {
            "enforcementState": "PAB_POLICY_ENFORCEMENT_STATE_NOT_ENFORCED",
            "version": 1
          },
          "relevance": "HEURISTIC_RELEVANCE_NORMAL"
        },
        "explainedPolicyBinding": {
          "conditionExplanation": {
            "evaluationStates": [
              {
                "end": 53,
                "value": true
              },
              {
                "end": 153,
                "start": 58,
                "value": false
              },
              {
                "end": 248,
                "start": 157,
                "value": false
              }
            ],
            "value": false
          },
          "policyBinding": {
            "condition": {
              "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && (principal.subject=='service-account-1@project-1.iam.gserviceaccount.com' || principal.subject=='service-account-2@project-1.iam.gserviceaccount.com')"
            },
            "createTime": "2024-04-09T17:51:13.504418Z",
            "displayName": "PAB Policy Binding on project-1 project",
            "etag": "W/\"hz9IKzHsIqvopqDRcVYDxQ==\"",
            "name": "projects/123456789012/locations/global/policyBindings/example-policy-binding",
            "policy": "organizations/123456789012/locations/global/principalAccessBoundaryPolicies/example-pab-policy",
            "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
            "policyUid": "puid_11875429267422576641",
            "target": {
              "principalSet": "//cloudresourcemanager.googleapis.com/projects/project-1"
            },
            "uid": "buid_1012746966204940289", 
            "updateTime": "2024-05-09T23:08:56.846355Z"
          },
          "policyBindingState": "POLICY_BINDING_STATE_NOT_ENFORCED",
          "relevance": "HEURISTIC_RELEVANCE_NORMAL"
        },
        "relevance": "HEURISTIC_RELEVANCE_NORMAL"
      }
    ],
    "principalAccessBoundaryAccessState": "PAB_ACCESS_STATE_NOT_ENFORCED",
    "relevance": "HEURISTIC_RELEVANCE_NORMAL"
  }
}

REST

Pour savoir pourquoi un compte principal dispose ou non d'une autorisation IAM, utilisez la méthode iam.troubleshoot de l'API Policy Troubleshooter.

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

  • VERSION : version de l'API à utiliser pour cette requête. Pour résoudre les problèmes d'accès basés uniquement sur les stratégies d'autorisation et de refus, utilisez v3. Pour résoudre les problèmes d'accès basés sur les stratégies d'autorisation, de refus et de limite d'accès des comptes principaux, utilisez v3beta.
  • EMAIL : adresse e-mail du compte principal dont vous souhaitez résoudre les problèmes d'autorisation.
  • RESOURCE : ressource pour laquelle l'autorisation est accordée.
  • PERMISSION : autorisation dont vous souhaitez résoudre les problèmes.
  • PROJECT_ID : ID du projet que vous souhaitez utiliser pour envoyer la requête. Les ID de projet sont des chaînes alphanumériques, telles que my-project.

Méthode HTTP et URL :

POST https://policytroubleshooter.googleapis.com/VERSION/iam:troubleshoot

Corps JSON de la requête :

{
  "accessTuple": {
    "principal": "EMAIL",
    "fullResourceName": "RESOURCE",
    "permission": "PERMISSION"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

Comprendre les résultats de l'outil de dépannage

Console

La page de résultats contient les informations suivantes :

Détails de l'évaluation

La section Détails de l'évaluation contient un récapitulatif de l'accès pour lequel vous résolvez les problèmes, y compris le compte principal, la ressource et l'autorisation spécifiés. Si vous dépannez plusieurs paires d'autorisations de ressources, vous pouvez utiliser la liste Évaluation de l'accès pour basculer entre elles.

Détails des règles

La section Détails de la stratégie contient des informations sur la façon dont les stratégies d'autorisation, de refus et de limite d'accès des comptes principaux concernées affectent l'accès du compte principal.

Les stratégies de limite d'accès des comptes principaux pertinentes incluent toutes les stratégies de limite d'accès des comptes principaux qui sont liées à un ensemble de comptes principaux incluant le compte principal.

Voici les stratégies d'autorisation et de refus concernées :

  • La stratégie d'autorisation de la ressource
  • Les règles de refus de la ressource, le cas échéant
  • Les stratégies d'autorisation du projet, du dossier et de l'organisation parent de la ressource, le cas échéant
  • Les stratégies de refus du projet, du dossier et de l'organisation parent de la ressource, le cas échéant

Les stratégies d'autorisation et de refus des projets, dossiers et organisations parents sont pertinentes en raison de l'héritage des stratégies. Lorsque vous associez une stratégie d'autorisation ou de refus à un projet, un dossier ou une organisation, cette stratégie s'applique également à toutes les ressources de ce projet, ce dossier ou cette organisation.

Par exemple, si une stratégie de refus pour une organisation indique qu'un compte principal ne peut pas utiliser une autorisation spécifique, le compte principal ne peut utiliser cette autorisation sur aucune ressource de l'organisation. Cette règle s'applique même si les dossiers et les projets de cette organisation sont associés à des stratégies de refus plus permissives ou à des stratégies d'autorisation qui accordent cette autorisation au compte principal.

De même, si une stratégie d'autorisation pour un projet accorde une autorisation spécifique à un compte principal, celui-ci dispose de cette autorisation pour n'importe quelle ressource du projet, à condition que cette autorisation ne lui soit pas refusée.

La section Détails de la règle contient les sections suivantes :

État de l'accès

La section État de l'accès résume les résultats pour chaque type de règle (stratégies de limite d'accès des comptes principaux, règles de refus et règles d'autorisation) et indique le résultat global. Le résultat indique si le compte principal est en mesure d'utiliser l'autorisation pour accéder à la ressource, conformément aux règles concernées.

Pour qu'un utilisateur puisse utiliser l'autorisation d'accéder à la ressource, tous les types de règles doivent autoriser l'accès. Pour en savoir plus, consultez Évaluation des stratégies.

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

Dans la section Stratégie de limite d'accès des comptes principaux, vous pouvez afficher toutes les stratégies de limite d'accès des comptes principaux auxquelles le compte principal est soumis, ainsi que les liaisons de stratégie qui lient ces stratégies au compte principal.

Le volet Stratégies liste toutes les stratégies liées à un ensemble de comptes principaux qui inclut le compte principal. À côté de chaque stratégie se trouve une icône indiquant comment elle affecte l'accès du compte principal.

Les stratégies de limite d'accès des comptes principaux peuvent affecter l'accès d'un compte principal de différentes manières :

  • Le compte principal est autorisé à accéder à la ressource : la stratégie de limite d'accès des comptes principaux s'applique au compte principal, et l'une de ses règles contient la ressource interrogée.
  • Le compte principal n'est pas autorisé à accéder à la ressource : la stratégie de limite d'accès des comptes principaux s'applique au compte principal, mais la ressource interrogée ne figure pas dans les règles de cette stratégie.
  • Non appliquée : les stratégies de limite d'accès des comptes principaux ne sont pas appliquées dans les cas suivants :

    • IAM n'applique pas l'autorisation spécifiée dans la version d'application de la stratégie de limite d'accès des comptes principaux. Par conséquent, la stratégie de limite d'accès des comptes principaux ne peut pas bloquer l'accès.
    • En raison d'une condition dans la liaison de stratégie, la stratégie ou la liaison de limite d'accès des comptes principaux ne s'applique pas au compte principal.
    • Une stratégie de limite d'accès de compte principal ne comporte aucune règle.

    Si une stratégie de limite d'accès des comptes principaux n'est pas appliquée, elle ne peut pas déterminer si le compte principal peut accéder à la ressource.

Pour afficher les règles et les liaisons associées à une stratégie de limite d'accès des comptes principaux, cliquez sur le nom de la stratégie. Le volet adjacent au volet Règles affiche les détails de la règle.

Pour afficher les règles de la stratégie, cliquez sur l'onglet Règles de limites. Cet onglet affiche un tableau des règles de stratégie de limite d'accès des comptes principaux concernées.

Une règle de limite d'accès de compte principal est pertinente si elle a un impact sur le résultat global de la requête Policy Troubleshooter. Par conséquent, les règles applicables varient en fonction des résultats de Policy Troubleshooter. Par exemple, prenons les situations suivantes :

  • Policy Troubleshooter indique que le compte principal peut accéder à la ressource. Par conséquent, les règles pertinentes sont celles qui permettent au compte principal d'accéder à la ressource.
  • Policy Troubleshooter indique que le compte principal ne peut pas accéder à la ressource. Toutefois, selon les stratégies de limite d'accès des comptes principaux concernées, le compte principal est autorisé à accéder à la ressource. Par conséquent, aucune règle n'est pertinente, car les stratégies de limite d'accès des comptes principaux ne sont pas la raison pour laquelle le compte principal ne peut pas accéder à la ressource.
  • Policy Troubleshooter indique que le compte principal ne peut pas accéder à la ressource. De plus, selon les règles de limite d'accès des comptes principaux concernées, le compte principal n'est pas autorisé à accéder à la ressource. Par conséquent, les règles pertinentes sont celles qui n'autorisent pas le compte principal à accéder à la ressource.

Pour afficher toutes les règles de limite d'accès des comptes principaux d'une stratégie, décochez la case Afficher uniquement les règles et liaisons pertinentes.

La colonne Résultats du tableau des règles de limite indique si la règle de limite d'accès des comptes principaux contient la ressource interrogée. Pour en savoir plus sur la règle, cliquez sur Afficher les détails de la règle.

Pour afficher les liaisons de la règle, cliquez sur l'onglet Liaisons. Cet onglet affiche un tableau des liaisons de stratégie pertinentes pour la stratégie de limite d'accès des comptes principaux sélectionnée.

Une liaison de stratégie est pertinente si elle applique efficacement la stratégie de limite d'accès des comptes principaux au compte principal interrogé. Pour qu'une liaison de stratégie applique une stratégie de limite d'accès des comptes principaux à un compte principal, les conditions suivantes doivent être remplies :

  • L'ensemble de comptes principaux défini dans la liaison de stratégie doit inclure le compte principal interrogé.
  • Toutes les conditions de la liaison de règle doivent renvoyer la valeur true pour le principal interrogé.

Pour afficher toutes les liaisons de stratégie avec des ensembles de comptes principaux qui incluent le compte principal interrogé, que ce dernier remplisse ou non la condition dans la liaison, décochez la case N'afficher que les règles et les liaisons pertinentes.

La colonne Résultats du tableau des liaisons indique si la liaison est appliquée au compte principal interrogé. Pour en savoir plus sur l'association de règles, cliquez sur Afficher les détails de l'association.

Règle de refus

Dans la section Stratégie de refus, vous pouvez afficher toutes les stratégies de refus pertinentes, identifier les règles de refus qui refusent l'accès au compte principal et comprendre pourquoi une règle de refus accorde ou refuse l'autorisation au compte principal.

Le volet Ressources avec des stratégies de refus liste toutes les stratégies de refus applicables, organisées par ressources auxquelles elles sont associées. Une évaluation de l'accès est affichée à côté de chaque stratégie de refus. Cette évaluation ne s'applique qu'à cette stratégie de refus. Elle ne reflète aucun accès provenant des stratégies héritées. Si vous n'êtes pas autorisé à afficher la règle de refus d'une ressource, la liste des ressources n'inclut pas cette ressource ni ses règles de refus.

Pour afficher les règles de refus pertinentes dans ces stratégies de refus, cliquez sur une stratégie de refus. Pour afficher toutes les règles de refus dans les stratégies de refus d'une ressource, cliquez sur une ressource. Les règles de refus s'affichent dans le volet Règles de refus. Ce volet contient un tableau de toutes les règles de refus avec le compte principal ou l'autorisation demandés pour la ressource ou la stratégie de refus que vous avez sélectionnées.

La colonne Accès indique si la règle de refus refuse l'autorisation au compte principal. Pour afficher plus de détails sur la règle de refus, cliquez sur Afficher la règle de refus dans la ligne correspondante.

Règle d'autorisation

Dans la section Stratégie d'autorisation, vous pouvez parcourir toutes les stratégies d'autorisation pertinentes, identifier les liaisons de rôles qui accordent l'accès au compte principal et comprendre pourquoi une liaison de rôle accorde ou non l'autorisation au compte principal.

Le volet Ressources liste la ressource spécifiée et ses ancêtres. Une évaluation de l'accès est indiquée à côté de chaque ressource. Cette évaluation ne s'applique qu'à la stratégie d'autorisation de cette ressource. Elle ne reflète aucun accès provenant de stratégies héritées. Si vous ne disposez pas des autorisations nécessaires pour afficher la règle d'autorisation d'une ressource, celle-ci n'apparaît pas dans la liste des ressources.

Pour afficher les liaisons de rôle pertinentes dans la stratégie d'autorisation d'une ressource et voir comment elles accordent ou non l'autorisation au compte principal, cliquez sur la ressource. Les liaisons de rôle de la stratégie d'autorisation s'affichent dans le volet Liaisons de rôle.

Le volet Liaisons de rôles contient un tableau des liaisons de rôles dans la stratégie d'autorisation de la ressource sélectionnée. Par défaut, le tableau ne contient que les liaisons de rôle qui incluent un rôle doté de l'autorisation spécifiée. Si le compte principal n'a pas d'accès, le tableau affiche également les liaisons de rôles avec des rôles personnalisés modifiables. Pour afficher toutes les liaisons de rôle, décochez la case Afficher uniquement les liaisons pertinentes.

La colonne Accès indique si la liaison de rôle accorde l'autorisation au compte principal. Pour afficher plus de détails sur la liaison de rôle, cliquez sur Afficher les détails de la liaison dans la ligne de cette liaison de rôle.

gcloud

La réponse contient quatre sections principales : une description du tuple d'accès dans la requête, les résultats de l'évaluation de la stratégie d'autorisation, les résultats de l'évaluation de la stratégie de refus et l'état d'accès global.

  • accessTuple : description du tuple d'accès dans la requête, y compris tout contexte de condition que vous avez fourni. Cette section contient également un récapitulatif des tags qui s'appliquent à la ressource.
  • allowPolicyExplanation : résumé indiquant si les stratégies d'autorisation concernées accordent l'autorisation au compte principal, suivi d'une liste des stratégies d'autorisation et de leurs liaisons de rôles.

    Pour chaque règle d'autorisation, la réponse liste toutes les liaisons de rôle de la règle et les évalue en fonction des critères suivants :

    • Indique si la liaison de rôle inclut l'autorisation.
    • Indique si la liaison de rôle inclut le compte principal.
    • Indique si les conditions de la liaison de rôle, le cas échéant, sont remplies.

    La réponse affiche ensuite le texte JSON complet de la stratégie d'autorisation.

  • denyPolicyExplanation : récapitulatif indiquant si les règles de refus pertinentes refusent l'autorisation au compte principal, suivi d'une liste des ressources avec des règles de refus. Pour chaque ressource, la réponse liste toutes les stratégies de refus qui lui sont associées.

    Pour chaque règle de refus, la réponse affiche les métadonnées de la règle, liste les règles de refus de la règle, puis évalue chaque règle en fonction des critères suivants :

    • Indique si la règle de refus inclut l'autorisation.
    • Indique si l'autorisation est répertoriée comme une exception dans la règle de refus.
    • Indique si la règle de refus inclut le compte principal.
    • Indique si le compte principal est listé comme exception dans la règle de refus.
    • Indique si les conditions de la règle de refus, le cas échéant, sont remplies.
  • overallAccessState : indique si le compte principal peut utiliser l'autorisation spécifiée pour accéder à la ressource spécifiée en fonction des stratégies d'autorisation, des stratégies de refus et des stratégies de limite d'accès des comptes principaux concernées.

    Les stratégies de limite d'accès des comptes principaux pertinentes incluent toutes les stratégies de limite d'accès des comptes principaux qui sont liées à un ensemble de comptes principaux incluant le compte principal.

    Voici les stratégies d'autorisation et de refus concernées :

    • La stratégie d'autorisation de la ressource
    • Les règles de refus de la ressource, le cas échéant
    • Les stratégies d'autorisation du projet, du dossier et de l'organisation parent de la ressource, le cas échéant
    • Les stratégies de refus du projet, du dossier et de l'organisation parent de la ressource, le cas échéant

    Les stratégies d'autorisation et de refus des projets, dossiers et organisations parents sont pertinentes en raison de l'héritage des stratégies. Lorsque vous associez une stratégie d'autorisation ou de refus à un projet, un dossier ou une organisation, cette stratégie s'applique également à toutes les ressources de ce projet, ce dossier ou cette organisation.

    Par exemple, si une stratégie de refus pour une organisation indique qu'un compte principal ne peut pas utiliser une autorisation spécifique, le compte principal ne peut utiliser cette autorisation sur aucune ressource de l'organisation. Cette règle s'applique même si les dossiers et les projets de cette organisation sont associés à des stratégies de refus plus permissives ou à des stratégies d'autorisation qui accordent cette autorisation au compte principal.

    De même, si une stratégie d'autorisation pour un projet accorde une autorisation spécifique à un compte principal, celui-ci dispose de cette autorisation pour n'importe quelle ressource du projet, à condition que cette autorisation ne lui soit pas refusée.

    Pour qu'un utilisateur puisse utiliser l'autorisation d'accéder à la ressource, tous les types de règles doivent autoriser l'accès. Pour en savoir plus, consultez Évaluation des règles.

  • pabPolicyExplanation : résumé indiquant si les stratégies de limite d'accès des comptes principaux concernées autorisent le compte principal à accéder à la ressource, suivi des liaisons de stratégies de limite d'accès des comptes principaux et des stratégies de limite d'accès des comptes principaux concernées.

    Les stratégies de limites d'accès des comptes principaux peuvent autoriser ou non l'accès, ou ne pas être appliquées. Les stratégies de limite d'accès des comptes principaux ne sont pas appliquées dans les cas suivants :

    • IAM n'applique pas l'autorisation spécifiée dans la version d'application de la stratégie de limite d'accès des comptes principaux. Par conséquent, la stratégie de limite d'accès des comptes principaux ne peut pas bloquer l'accès.
    • En raison d'une condition dans la liaison de stratégie, la stratégie ou la liaison de limite d'accès des comptes principaux ne s'applique pas au compte principal.
    • Une stratégie de limite d'accès de compte principal ne comporte aucune règle.

    Si une stratégie de limite d'accès des comptes principaux n'est pas appliquée, elle ne peut pas déterminer si le compte principal peut accéder à la ressource.

    La réponse liste également toutes les liaisons de stratégie qui incluent le compte principal, ainsi que les détails de la stratégie de limite d'accès des comptes principaux dans chacune de ces liaisons de stratégie :

    • Pour chaque liaison de stratégie de limite d'accès des comptes principaux, la réponse indique si la liaison de stratégie est appliquée au compte principal, puis affiche le texte de la liaison de stratégie. Une liaison de stratégie est appliquée si l'ensemble de comptes principaux de la liaison inclut le compte principal interrogé et si la condition de la liaison de stratégie renvoie la valeur true pour le compte principal interrogé. Si la liaison de stratégie n'est pas appliquée, la stratégie ne peut pas déterminer si le compte principal peut accéder à la ressource.
    • Pour chaque stratégie de limite d'accès des comptes principaux, la réponse affiche les éléments suivants :

      • Indique si la stratégie autorise l'accès, ne l'autorise pas ou n'est pas appliquée.
      • Version de la règle appliquée. Ce numéro de version détermine si IAM applique cette stratégie de limite d'accès des comptes principaux pour l'autorisation interrogée. Si l'autorisation n'est pas appliquée, la stratégie ne peut pas déterminer si le compte principal peut accéder à la ressource.
      • Les règles de la stratégie de limite d'accès des comptes principaux et si chaque règle autorise l'accès. Pour chaque règle, la réponse indique si la ressource demandée est incluse dans la règle.

        Une ressource est incluse dans une règle si l'une des conditions suivantes est remplie :

        • La ressource est listée dans la règle. Seules les ressources Resource Manager (projets, dossiers et organisations) peuvent être listées directement dans les règles de limites d'accès de compte principal.
        • Un des ancêtres de la ressource (c'est-à-dire un projet, un dossier ou une organisation au-dessus de la ressource dans la hiérarchie des ressources) est listé dans la règle.
  • De nombreux objets de la réponse comportent également un champ relevance. La valeur de ce champ indique la contribution de cet objet à l'état d'accès global. Le champ relevance peut présenter les valeurs suivantes :

    • HEURISTIC_RELEVANCE_HIGH : indique que l'objet a un impact important sur le résultat. En d'autres termes, la suppression de l'objet modifiera probablement l'état d'accès global. Par exemple, une liaison de rôle qui accorde au compte principal l'autorisation spécifiée aurait cette valeur de pertinence.

    • HEURISTIC_RELEVANCE_NORMAL : indique que l'objet a un impact limité sur le résultat. En d'autres termes, la suppression de l'objet ne devrait pas modifier l'état d'accès global. Par exemple, une règle de refus qui ne contient pas l'autorisation ni le principal aurait cette valeur de pertinence.

    REST

    La réponse contient quatre sections principales : l'état d'accès global, une description du tuple d'accès dans la requête, les résultats de l'évaluation de la règle d'autorisation et les résultats de l'évaluation de la règle de refus.

    • overallAccessState : indique si le compte principal peut utiliser l'autorisation spécifiée pour accéder à la ressource spécifiée en fonction des stratégies d'autorisation, des stratégies de refus et des stratégies de limite d'accès des comptes principaux concernées.

      Les stratégies de limite d'accès des comptes principaux pertinentes incluent toutes les stratégies de limite d'accès des comptes principaux qui sont liées à un ensemble de comptes principaux incluant le compte principal.

      Voici les stratégies d'autorisation et de refus concernées :

      • La stratégie d'autorisation de la ressource
      • Les règles de refus de la ressource, le cas échéant
      • Les stratégies d'autorisation du projet, du dossier et de l'organisation parent de la ressource, le cas échéant
      • Les stratégies de refus du projet, du dossier et de l'organisation parent de la ressource, le cas échéant

      Les stratégies d'autorisation et de refus des projets, dossiers et organisations parents sont pertinentes en raison de l'héritage des stratégies. Lorsque vous associez une stratégie d'autorisation ou de refus à un projet, un dossier ou une organisation, cette stratégie s'applique également à toutes les ressources de ce projet, ce dossier ou cette organisation.

      Par exemple, si une stratégie de refus pour une organisation indique qu'un compte principal ne peut pas utiliser une autorisation spécifique, le compte principal ne peut utiliser cette autorisation sur aucune ressource de l'organisation. Cette règle s'applique même si les dossiers et les projets de cette organisation sont associés à des stratégies de refus plus permissives ou à des stratégies d'autorisation qui accordent cette autorisation au compte principal.

      De même, si une stratégie d'autorisation pour un projet accorde une autorisation spécifique à un compte principal, celui-ci dispose de cette autorisation pour n'importe quelle ressource du projet, à condition que cette autorisation ne lui soit pas refusée.

      Pour qu'un utilisateur puisse utiliser l'autorisation d'accéder à la ressource, tous les types de règles doivent autoriser l'accès. Pour en savoir plus, consultez Évaluation des règles.

    • accessTuple : description du tuple d'accès dans la requête, y compris tout contexte de condition que vous avez fourni. Cette section contient également un récapitulatif des tags qui s'appliquent à la ressource.
    • allowPolicyExplanation : résumé indiquant si les stratégies d'autorisation concernées accordent l'autorisation au compte principal, suivi d'une liste des stratégies d'autorisation et de leurs liaisons de rôles.

      Pour chaque règle d'autorisation, la réponse liste toutes les liaisons de rôle de la règle et les évalue en fonction des critères suivants :

      • Indique si la liaison de rôle inclut l'autorisation.
      • Indique si la liaison de rôle inclut le compte principal.
      • Indique si les conditions de la liaison de rôle, le cas échéant, sont remplies.

      La réponse affiche ensuite le texte JSON complet de la stratégie d'autorisation.

    • denyPolicyExplanation : récapitulatif indiquant si les règles de refus pertinentes refusent l'autorisation au compte principal, suivi d'une liste des ressources avec des règles de refus. Pour chaque ressource, la réponse liste toutes les stratégies de refus qui lui sont associées.

      Pour chaque règle de refus, la réponse affiche les métadonnées de la règle, liste les règles de refus de la règle, puis évalue chaque règle en fonction des critères suivants :

      • Indique si la règle de refus inclut l'autorisation.
      • Indique si l'autorisation est répertoriée comme une exception dans la règle de refus.
      • Indique si la règle de refus inclut le compte principal.
      • Indique si le compte principal est listé comme exception dans la règle de refus.
      • Indique si les conditions de la règle de refus, le cas échéant, sont remplies.
    • pabPolicyExplanation : résumé indiquant si les stratégies de limite d'accès des comptes principaux concernées autorisent le compte principal à accéder à la ressource, suivi des liaisons de stratégies de limite d'accès des comptes principaux et des stratégies de limite d'accès des comptes principaux concernées.

      Les stratégies de limites d'accès des comptes principaux peuvent autoriser ou non l'accès, ou ne pas être appliquées. Les stratégies de limite d'accès des comptes principaux ne sont pas appliquées dans les cas suivants :

      • IAM n'applique pas l'autorisation spécifiée dans la version d'application de la stratégie de limite d'accès des comptes principaux. Par conséquent, la stratégie de limite d'accès des comptes principaux ne peut pas bloquer l'accès.
      • En raison d'une condition dans la liaison de stratégie, la stratégie ou la liaison de limite d'accès des comptes principaux ne s'applique pas au compte principal.
      • Une stratégie de limite d'accès de compte principal ne comporte aucune règle.

      Si une stratégie de limite d'accès des comptes principaux n'est pas appliquée, elle ne peut pas déterminer si le compte principal peut accéder à la ressource.

      La réponse liste également toutes les liaisons de stratégie qui incluent le compte principal, ainsi que les détails de la stratégie de limite d'accès des comptes principaux dans chacune de ces liaisons de stratégie :

      • Pour chaque liaison de stratégie de limite d'accès des comptes principaux, la réponse indique si la liaison de stratégie est appliquée au compte principal, puis affiche le texte de la liaison de stratégie. Une liaison de stratégie est appliquée si l'ensemble de comptes principaux de la liaison inclut le compte principal interrogé et si la condition de la liaison de stratégie renvoie la valeur true pour le compte principal interrogé. Si la liaison de stratégie n'est pas appliquée, la stratégie ne peut pas déterminer si le compte principal peut accéder à la ressource.
      • Pour chaque stratégie de limite d'accès des comptes principaux, la réponse affiche les éléments suivants :

        • Indique si la stratégie autorise l'accès, ne l'autorise pas ou n'est pas appliquée.
        • Version de la règle appliquée. Ce numéro de version détermine si IAM applique cette stratégie de limite d'accès des comptes principaux pour l'autorisation interrogée. Si l'autorisation n'est pas appliquée, la stratégie ne peut pas déterminer si le compte principal peut accéder à la ressource.
        • Les règles de la stratégie de limite d'accès des comptes principaux et si chaque règle autorise l'accès. Pour chaque règle, la réponse indique si la ressource demandée est incluse dans la règle.

          Une ressource est incluse dans une règle si l'une des conditions suivantes est remplie :

          • La ressource est listée dans la règle. Seules les ressources Resource Manager (projets, dossiers et organisations) peuvent être listées directement dans les règles de limites d'accès de compte principal.
          • Un des ancêtres de la ressource (c'est-à-dire un projet, un dossier ou une organisation au-dessus de la ressource dans la hiérarchie des ressources) est listé dans la règle.

    De nombreux objets de la réponse comportent également un champ relevance. La valeur de ce champ indique la contribution de cet objet à l'état d'accès global. Le champ relevance peut présenter les valeurs suivantes :

    • HEURISTIC_RELEVANCE_HIGH : indique que l'objet a un impact important sur le résultat. En d'autres termes, la suppression de l'objet modifiera probablement l'état d'accès global. Par exemple, une liaison de rôle qui accorde au compte principal l'autorisation spécifiée aurait cette valeur de pertinence.

    • HEURISTIC_RELEVANCE_NORMAL : indique que l'objet a un impact limité sur le résultat. En d'autres termes, la suppression de l'objet ne devrait pas modifier l'état d'accès global. Par exemple, une règle de refus qui ne contient pas l'autorisation ni le principal aurait cette valeur de pertinence.

    Dépanner des liaisons de rôles conditionnelles

    L'outil de dépannage des règles résout automatiquement les problèmes liés aux liaisons de rôles conditionnelles et aux règles de refus en fonction des tags. Il résout également automatiquement les problèmes liés aux liaisons de stratégie de limite d'accès des comptes principaux avec des conditions basées sur les comptes principaux.

    Pour résoudre les problèmes liés à d'autres types de liaisons de rôles conditionnelles ou de règles de refus conditionnelles, Policy Troubleshooter nécessite un contexte supplémentaire sur la requête. Par exemple, pour résoudre les problèmes liés à des conditions basées sur des attributs de date/heure, Policy Troubleshooter nécessite l'heure de la requête.

    Dans gcloud CLI et l'API REST, vous devez fournir ce contexte supplémentaire manuellement.

    Dans la console Google Cloud , vous pouvez fournir ce contexte supplémentaire en résolvant directement le problème à partir de n'importe quel journal d'audit des activités d'administration ou journal d'audit des accès aux données. Chaque entrée de journal d'audit correspond à une requête adressée à une API Google Cloud ou à une action effectuée par Google Cloud de votre part. Lorsque vous résolvez des problèmes à partir d'un journal d'audit, Policy Troubleshooter obtient automatiquement des informations supplémentaires sur la requête, telles que sa date et son heure. Cela lui permet d'analyser les liaisons de rôles conditionnelles et les règles de refus.

    Console

    Pour résoudre les problèmes liés aux liaisons de rôles conditionnelles et aux règles de refus, procédez comme suit :

    1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

      Accédez à l'explorateur de journaux.

    2. Si le titre de la page est Legacy Logs Viewer (Ancienne version de la visionneuse de journaux), cliquez sur la liste déroulante Upgrade (Mettre à niveau) et sélectionnez Upgrade to new Logs Explorer (Mettre à niveau vers le nouvel explorateur de journaux).

    3. Pour n'afficher que les journaux d'audit des activités d'administration et des accès aux données, saisissez la requête suivante dans le générateur de requêtes, puis cliquez sur Exécuter la requête :

      logName=("RESOURCE_TYPE/RESOURCE_ID/logs/cloudaudit.googleapis.com%2Factivity" OR "RESOURCE_TYPE/RESOURCE_ID/logs/cloudaudit.googleapis.com%2Fdata_access")
      

      Remplacez les valeurs suivantes :

      • RESOURCE_TYPE : type de ressource pour lequel vous souhaitez répertorier les journaux d'audit. Utilisez projects, folders ou organizations.
      • RESOURCE_ID : ID de votre ressource.
    4. Recherchez l'entrée du journal d'audit qui correspond à la requête que vous souhaitez résoudre. Pour découvrir comment rechercher des entrées de journal spécifiques à l'aide de l'explorateur de journaux, consultez la page Utiliser l'explorateur de journaux.

    5. Dans la colonne Résumé de l'entrée de journal, cliquez sur IAM, puis sur Résoudre un problème d'accès.

      Policy Troubleshooter utilise les informations de l'entrée de journal pour résoudre les problèmes d'accès, puis affiche les résultats. Le contexte supplémentaire est indiqué dans les détails de l'évaluation, sous Contexte de la condition. Pour afficher les détails du contexte, cliquez sur Afficher le contexte de la condition. Pour en savoir plus sur la page de résultats de Policy Troubleshooter, consultez la section Comprendre les résultats de l'outil de dépannage de cette page.

    6. Facultatif : Pour résoudre les problèmes concernant une autre requête impliquant des liaisons de rôles conditionnelles et des règles de refus, revenez à la page Explorateur de journaux et répétez les étapes précédentes.

    gcloud

    Pour résoudre les problèmes liés aux liaisons de rôles conditionnelles et aux règles de refus, utilisez la commande gcloud policy-troubleshoot iam.

    Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

    • EMAIL : adresse e-mail du compte principal dont vous souhaitez résoudre les problèmes d'autorisation.
    • RESOURCE : ressource pour laquelle l'autorisation est accordée.
    • PERMISSION : autorisation dont vous souhaitez résoudre les problèmes.
    • DESTINATION_IP : facultatif. Adresse IP de destination de la requête à utiliser lors de la vérification des liaisons de rôle conditionnelles. Exemple : 198.1.1.1.
    • DESTINATION_PORT : facultatif. Port de destination de la requête à utiliser lors de la vérification des liaisons de rôle conditionnelles. Par exemple, `8080`.
    • REQUEST_TIME : facultatif. Code temporel de la requête à utiliser lors de la vérification des liaisons de rôles conditionnelles. Utilisez un code temporel au format RFC 3339, par exemple 2099-02-01T00:00:00Z.
    • RESOURCE_NAME : facultatif. Valeur du nom de ressource à utiliser lors de la vérification des liaisons de rôle conditionnelles. Pour obtenir la liste des formats de nom de ressource acceptés, consultez Format du nom des ressources.
    • RESOURCE_SERVICE : facultatif. Valeur du service de ressources à utiliser lors de la vérification des liaisons de rôle conditionnelles. Pour obtenir la liste des noms de service acceptés, consultez la section Valeurs du service de ressources.
    • RESOURCE_TYPE : facultatif. Pour obtenir la liste des types de ressources acceptés, consultez la section Valeurs du type de ressource.

    Exécutez la commande gcloud policy-troubleshoot iam :

    Linux, macOS ou Cloud Shell

    gcloud policy-intelligence troubleshoot-policy iam RESOURCE --principal-email=EMAIL \
        --permission=PERMISSION --destination-ip=DESTINATION_IP \
        --destination-port=DESTINATION_PORT --request-time=REQUEST_TIME \
        --resource-name=RESOURCE_NAME --resource-service=RESOURCE_SERVICE \
        --resource-type=RESOURCE_TYPE

    Windows (PowerShell)

    gcloud policy-intelligence troubleshoot-policy iam RESOURCE --principal-email=EMAIL `
        --permission=PERMISSION --destination-ip=DESTINATION_IP `
        --destination-port=DESTINATION_PORT --request-time=REQUEST_TIME `
        --resource-name=RESOURCE_NAME --resource-service=RESOURCE_SERVICE `
        --resource-type=RESOURCE_TYPE

    Windows (cmd.exe)

    gcloud policy-intelligence troubleshoot-policy iam RESOURCE --principal-email=EMAIL ^
        --permission=PERMISSION --destination-ip=DESTINATION_IP ^
        --destination-port=DESTINATION_PORT --request-time=REQUEST_TIME ^
        --resource-name=RESOURCE_NAME --resource-service=RESOURCE_SERVICE ^
        --resource-type=RESOURCE_TYPE

    La réponse contient une explication de l'accès du compte principal. Pour chaque liaison de rôle et règle de refus avec une condition, la réponse inclut un champ conditionExplanation qui indique si la condition est évaluée comme "true" ou "false" en fonction du contexte de condition que vous avez fourni.

    Par exemple, voici une évaluation d'une liaison de rôle avec une condition spécifiant le type de ressource et le service de ressources :

    Réponse

    ...
    {
      "allowAccessState": "ALLOW_ACCESS_STATE_GRANTED",
      "combinedMembership": {
        "membership": "MEMBERSHIP_MATCHED",
        "relevance": "HEURISTIC_RELEVANCE_HIGH"
      },
      "condition": {
        "expression": " resource.type \u003d\u003d \"compute.googleapis.com/Instance\" \u0026\u0026 resource.service \u003d\u003d \"compute.googleapis.com\"",
        "title": "Compute instances only",
        "description": "Condition that limits permissions to only Compute instances"
      },
      "conditionExplanation": {
        "evaluationStates": [{
          "end": 51,
          "start": 1,
          "value": true
        }, {
          "end": 99,
          "start": 55,
          "value": true
        }],
        "value": true,
      },
      "memberships": {
        "user:my-user@example.com": {
          "membership": "MEMBERSHIP_MATCHED",
          "relevance": "HEURISTIC_RELEVANCE_HIGH"
        }
      },
      "relevance": "HEURISTIC_RELEVANCE_HIGH",
      "role": "roles/compute.viewer",
      "rolePermission": "ROLE_PERMISSION_INCLUDED",
      "rolePermissionRelevance": "HEURISTIC_RELEVANCE_HIGH"
    }
    ...
    

    REST

    Pour résoudre les problèmes liés aux liaisons de rôles conditionnelles et aux règles de refus, utilisez la méthode iam.troubleshoot de l'API Policy Troubleshooter.

    Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :

    • EMAIL : adresse e-mail du compte principal dont vous souhaitez résoudre les problèmes d'autorisation.
    • RESOURCE : ressource pour laquelle l'autorisation est accordée.
    • PERMISSION : autorisation dont vous souhaitez résoudre les problèmes.
    • DESTINATION_IP : facultatif. Adresse IP de destination de la requête à utiliser lors de la vérification des liaisons de rôle conditionnelles. Exemple : 198.1.1.1.
    • DESTINATION_PORT : facultatif. Port de destination de la requête à utiliser lors de la vérification des liaisons de rôle conditionnelles. Par exemple, `8080`.
    • REQUEST_TIME : facultatif. Code temporel de la requête à utiliser lors de la vérification des liaisons de rôles conditionnelles. Utilisez un code temporel au format RFC 3339, par exemple 2099-02-01T00:00:00Z.
    • RESOURCE_NAME : facultatif. Valeur du nom de ressource à utiliser lors de la vérification des liaisons de rôle conditionnelles. Pour obtenir la liste des formats de nom de ressource acceptés, consultez Format du nom des ressources.
    • RESOURCE_SERVICE : facultatif. Valeur du service de ressources à utiliser lors de la vérification des liaisons de rôle conditionnelles. Pour obtenir la liste des noms de service acceptés, consultez Valeurs du service de ressources.
    • RESOURCE_TYPE : facultatif. Pour obtenir la liste des types de ressources acceptés, consultez la section Valeurs du type de ressource.

    Méthode HTTP et URL :

    POST https://policytroubleshooter.googleapis.com/v3/iam:troubleshoot

    Corps JSON de la requête :

    {
      "accessTuple": {
        "principal": "EMAIL",
        "fullResourceName": "RESOURCE",
        "permission": "PERMISSION",
        "conditionContext": {
          "destination": {
            "ip": DESTINATION_IP,
            "port": DESTINATION_PORT
          },
          "request": {
            "receiveTime": REQUEST_TIME
          },
          "resource": {
            "name": RESOURCE_NAME,
            "service": RESOURCE_SERVICE,
            "type": RESOURCE_TYPE
          }
        }
      }
    }
    

    Pour envoyer votre requête, développez l'une des options suivantes :

    La réponse contient une explication de l'accès du compte principal. Pour chaque liaison de rôle et règle de refus avec une condition, la réponse inclut un champ conditionExplanation qui indique si la condition est évaluée comme "true" ou "false" en fonction du contexte de condition que vous avez fourni.

    Par exemple, voici une évaluation d'une liaison de rôle avec une condition spécifiant le type de ressource et le service de ressources :

    ...
    {
      "allowAccessState": "ALLOW_ACCESS_STATE_GRANTED",
      "role": "roles/compute.viewer",
      "rolePermission": "ROLE_PERMISSION_INCLUDED",
      "rolePermissionRelevance": "HEURISTIC_RELEVANCE_HIGH",
      "combinedMembership": {
        "membership": "MEMBERSHIP_MATCHED",
        "relevance": "HEURISTIC_RELEVANCE_HIGH"
      },
      "memberships": {
        "user:my-user@example.com": {
          "membership": "MEMBERSHIP_MATCHED",
          "relevance": "HEURISTIC_RELEVANCE_HIGH"
        }
      },
      "relevance": "HEURISTIC_RELEVANCE_HIGH",
      "condition": {
        "expression": " resource.type \u003d\u003d \"compute.googleapis.com/Instance\" \u0026\u0026 resource.service \u003d\u003d \"compute.googleapis.com\"",
        "title": "Compute instances only",
        "description": "Condition that limits permissions to only Compute instances"
      },
      "conditionExplanation": {
        "value": true,
        "evaluationStates": [{
          "start": 1,
          "end": 51,
          "value": true
        }, {
          "start": 55,
          "end": 99,
          "value": true
        }]
      }
    }
    ...
    

    Étapes suivantes