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

Policy Troubleshooter vous aide à déterminer si un compte principal peuvent accéder à une ressource. Avec un compte principal, une ressource et une autorisation, Policy Troubleshooter examine les stratégies d'autorisation, de refus et des stratégies de limite d'accès de compte principal (PAB) qui ont une incidence 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 les stratégies et explique comment elles affectent l'accès du compte principal.

Vous pouvez accéder à Policy Troubleshooter la console Google Cloud, la Google Cloud CLI ou l'API REST. Standard la console Google Cloud est généralement plus rapide. Pour les modèles plus complexes, utilisez plutôt gcloud CLI ou l'API REST.

Avant de commencer

  • Activez l'API Policy Troubleshooter

    Activer l'API

Autorisations requises

Pour résoudre les problèmes liés à l'utilisation vous avez besoin des éléments suivants : autorisations.

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

Policy Troubleshooter analyse l'accès d'un compte principal à une ressource en fonction des règles d'autorisation, de refus, de limite d'accès de compte principal et que vous êtes autorisé à afficher. Si vous n'êtes pas autorisé à afficher un qui s'applique à une ressource, ou si vous n'êtes pas autorisé à afficher vous ne pourrez peut-être pas savoir si un compte principal y a accès.

Pour obtenir les autorisations dont vous avez besoin pour résoudre les problèmes d'accès d'un compte principal, demandez à votre administrateur de vous accorder le les rôles IAM suivants au niveau de l'organisation:

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

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

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

Si vos règles d'autorisation et de refus incluent des groupes, vous devez disposer du rôle Google Workspace Autorisation groups.read pour l'API Admin permettant de résoudre les problèmes d'accès pour un groupe individuel membres. Les super-administrateurs et les administrateurs de groupe disposent automatiquement de cette autorisation. À accordez cette autorisation à un utilisateur qui n'est pas un super-administrateur ni un administrateur de groupe, créez une Administrateur Google Workspace qui contient le rôle 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 contenant les groupes ou les domaines ont pour résultat d'accès Unknown, sauf si la liaison de rôle ou de refus inclut également explicitement le compte principal.

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

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

Si vous ne disposez pas de ces autorisations, les liaisons de rôles et les règles de refus contenant les groupes ou les domaines ont pour résultat d'accès Unknown, sauf si la liaison de rôle ou 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. D'autres types de comptes principaux, y compris les groupes, les domaines, les identités des employés et les identités de charge de travail, ne sont pas compatibles.
  • Ressource : le nom complet de la ressource. Par exemple, pour vérifier le 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 les console Google Cloud, qui affiche une liste de suggestions à mesure que vous saisissez du texte.

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

    Pour obtenir la liste complète des autorisations, consultez la section Autorisations référence.

Console

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

  1. Dans la console Google Cloud, accédez à 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 complet de la ressource à vérifier.

    Si vous ne connaissez pas le nom complet de la ressource, effectuez l'une des opérations suivantes:

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

      1. Dans la zone Sélectionner un champ d'application, sélectionnez un projet, un dossier ou dans laquelle effectuer des recherches.
      2. Dans la zone Type de ressource, sélectionnez les types de ressources que vous souhaitez que vous recherchez.
      3. Dans le champ Rechercher des ressources, saisissez une partie de la ressource. son nom.
      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 à saisir du texte pour afficher la saisie semi-automatique options.

  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 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 en fonction de stratégies d'autorisation et de refus uniquement, ne spécifiez pas de version. Pour résoudre les problèmes d'accès en fonction des règles d'autorisation, de refus et de limite d'accès de compte principal, 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 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 l'API Policy Troubleshooter iam.troubleshoot .

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 en fonction de règles d'autorisation et de refus uniquement, utilisez v3. Pour résoudre les problèmes liés aux accès sur les règles d'autorisation, de refus et de limite d'accès de compte principal, 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ésumé de l'accès dont vous le dépannage, 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 Accéder à la liste d'évaluation pour passer de l'une à l'autre.

Détails des règles

La section Détails des règles explique comment les règles concernées autorisent, et les stratégies de limite d'accès de compte principal affectent l'accès du compte principal.

Les stratégies pertinentes de limite d'accès de compte principal incluent toutes les règles de limite d'accès de compte principal qui sont liés à un ensemble de comptes principaux qui l'inclut.

Les règles d'autorisation et de refus applicables sont les suivantes:

  • 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

Stratégies d'autorisation et de refus des projets, dossiers et organisations parents sont pertinentes en raison de l'héritage des règles. 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 des règles contient les sections suivantes:

État d'accès

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

Pour qu'un utilisateur puisse utiliser l'autorisation d'accès à la ressource, toutes les stratégies doivent autoriser l'accès. Pour en savoir plus, consultez la section Règles évaluation.

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 les stratégies de limite d'accès de compte principal auxquelles il est soumis et la règle qui lient ces stratégies au compte principal.

Le volet Règles répertorie toutes les règles liées à un ensemble de comptes principaux inclut le compte principal. À côté de chaque règle se trouve une icône indiquant comment 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 éligible à accéder à la ressource: la stratégie de limite d'accès de compte principal s'applique 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 de compte principal s'applique au compte principal, la ressource interrogée ne figure pas dans les règles de cette stratégie.
  • Non appliqué: Les stratégies de limite d'accès des comptes principaux ne sont pas appliquées dans les cas suivants:

    Si une règle de limite d'accès de compte principal n'est pas appliquée, cela n'a pas d'incidence 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 de compte principal, cliquez sur le nom de la règle. Le volet adjacent à Policies (Règles) affiche les les détails de la règle.

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

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 pertinentes varient en fonction des résultats de Policy Troubleshooter. Par exemple : vous pouvez envisager les situations suivantes:

  • Policy Troubleshooter indique que le compte principal peut accéder la ressource. Par conséquent, les règles pertinentes sont celles principal éligible à accéder à la ressource.
  • Policy Troubleshooter indique que le compte principal ne peut pas accéder la ressource. Toutefois, conformément aux stratégies de limites d'accès principales applicables, le compte principal peut accéder à la ressource. Par conséquent, aucune règle n'est car les stratégies de limite d'accès de compte principal ne sont pas la raison ne peut pas accéder à la ressource.
  • Policy Troubleshooter indique que le compte principal ne peut pas accéder la ressource. De plus, en fonction de la limite d'accès de compte principal appropriée, stratégies, le compte principal n'est pas autorisé à accéder à la ressource. Par conséquent, les règles pertinentes sont celles qui ne rendent pas le compte principal éligible à l'accès la ressource.

Pour afficher toutes les règles de limite d'accès de compte principal dans une stratégie, désélectionnez l'option Afficher uniquement les "règles et liaisons".

La colonne Résultats du tableau des règles de limite indique si le de limite d'accès de compte principal 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 stratégie, cliquez sur l'onglet Liaisons. Cet onglet affiche un tableau des liaisons de stratégie pertinentes pour la sélection de limite d'accès de compte principal.

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

  • Le compte principal défini dans la liaison de stratégie doit inclure le compte principal interrogé
  • Toutes les conditions de la liaison de stratégie doivent renvoyer la valeur true pour la requête principal.

Pour afficher toutes les liaisons de stratégie avec des ensembles de comptes principaux incluant les compte principal interrogé, qu'il remplisse ou non la condition de la liaison, décochez la case Afficher uniquement les règles et les liaisons pertinentes.

La colonne Findings de la table des liaisons indique si la liaison est pour le compte principal interrogé. Pour en savoir plus sur cette règle, cliquez sur Afficher les détails de la liaison.

Règle de refus

Dans la section Règle 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 un refus refuse ou ne refuse pas l'autorisation au compte principal.

Le volet Ressources avec des règles de refus répertorie toutes les règles de refus pertinentes. organisées en fonction des ressources auxquelles ils sont rattachés. À côté de chaque règle de refus, à l'évaluation des accès. Cette évaluation ne s'applique qu'à cette règle de refus, ne reflète pas les accès issus des règles héritées. Si vous ne dispose pas des autorisations nécessaires pour afficher la stratégie de refus d'une ressource, la liste de ressources n'incluent pas cette ressource ni ses stratégies de refus.

Pour afficher les règles de refus pertinentes dans ces stratégies de refus, cliquez sur une stratégie de refus. À affichez toutes les règles de refus dans les stratégies de refus d'une ressource, cliquez sur une ressource. Le refus apparaissent dans le volet Règles de refus. Ce volet contient une table de tous les refus des règles avec le compte principal interrogé ou l'autorisation 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 au compte principal l'autorisation. Pour en savoir plus 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 Règle d'autorisation, vous pouvez parcourir toutes les règles d'autorisation les stratégies, identifier les liaisons de rôles qui accordent l'accès au compte principal comprendre pourquoi une liaison de rôle donne ou ne donne pas au compte principal l'autorisation.

Le volet Ressources répertorie la ressource spécifiée et ses ancêtres. À côté de chaque ressource est une évaluation de l'accès. Cette évaluation ne s'applique la règle d'autorisation de la ressource. Elle ne tient pas compte des accès des règles. Si vous ne disposez pas des autorisations nécessaires pour afficher les la règle d'autorisation, la liste de ressources n'inclut pas cette ressource.

Pour afficher les liaisons de rôles pertinentes dans la stratégie d'autorisation d'une ressource et consulter comment il accorde ou non l'autorisation au compte principal, cliquez sur ressource. Les liaisons de rôles de la stratégie d'autorisation apparaissent dans Liaisons de rôles. volet.

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

La colonne Accès indique si la liaison de rôle accorde au compte principal le rôle l'autorisation. Pour en savoir plus sur la liaison de rôle, cliquez sur Afficher la liaison details sur la ligne de cette liaison de rôle.

gcloud

La réponse contient quatre sections principales: une description du tuple d'accès dans les résultats de l'évaluation de la stratégie d'autorisation, les résultats l'évaluation de la stratégie de refus et l'état de l'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ésumé des balises que à la ressource.
  • allowPolicyExplanation: récapitulatif indiquant si la propriété accordent l'autorisation au compte principal, suivie d'une liste et leurs liaisons de rôles.

    Pour chaque stratégie d'autorisation, la réponse répertorie toutes les liaisons de rôles dans la stratégie. 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 imprime ensuite le texte JSON complet de la stratégie d'autorisation.

  • denyPolicyExplanation: un résumé indiquant si le refus concerné Les stratégies refusent l'autorisation au compte principal, suivie d'une liste de ressources à l'aide de stratégies de refus. Pour chaque ressource, la réponse répertorie toutes les stratégies de refus associée à la ressource.

    Pour chaque stratégie de refus, la réponse imprime les métadonnées de la stratégie, répertorie les des règles de refus de la stratégie, puis évalue chaque règle en fonction des critères:

    • Indique si la règle de refus inclut l'autorisation.
    • Indique si l'autorisation est répertoriée en tant qu'exception dans la règle de refus.
    • Indique si la règle de refus inclut le compte principal.
    • Indique si le compte principal est répertorié en tant qu'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 est en mesure d'utiliser le l'autorisation spécifiée pour accéder à la ressource spécifiée en fonction les stratégies d'autorisation, de refus et de limite d'accès de compte principal.

    Les stratégies pertinentes de limite d'accès de compte principal incluent toutes les règles de limite d'accès de compte principal qui sont liés à un ensemble de comptes principaux qui l'inclut.

    Les règles d'autorisation et de refus applicables sont les suivantes:

    • 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

    Stratégies d'autorisation et de refus des projets, dossiers et organisations parents sont pertinentes en raison de l'héritage des règles. 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ès à la ressource, les types de stratégies doivent autoriser l’accès. Pour en savoir plus, consultez la section Évaluation des stratégies.

  • pabPolicyExplanation: résumé indiquant si les éléments les stratégies de limite d'accès de compte principal lui permettent d'accéder puis des liaisons de stratégie de limite d'accès de compte principal pertinentes de limites d'accès de compte principal.

    Les stratégies de limites d'accès des comptes principaux peuvent autoriser l'accès, mais pas l'autoriser, ou de ne pas être appliquées. Les stratégies de limite d'accès des comptes principaux ne sont pas appliquées dans le situations suivantes:

    Si une règle de limite d'accès de compte principal n'est pas appliquée, cela n'a pas d'incidence le compte principal peut accéder à la ressource.

    La réponse répertorie également toutes les liaisons de stratégie qui incluent le compte principal et les détails de la stratégie de limite d'accès de compte principal dans chacune de ces stratégies de liaison:

    • Pour chaque liaison de stratégie de limite d'accès de compte principal, la réponse indique si la liaison de stratégie est appliquée au compte principal, puis imprime le texte la liaison de stratégie. Une liaison de stratégie est appliquée si le compte principal la liaison inclut le compte principal interrogé, et si la condition dans le La liaison de stratégie prend la valeur true pour le compte principal interrogé. Si la liaison de stratégie n'est pas appliquée, la stratégie n'a pas d'incidence sur l'état le compte principal peut accéder à la ressource.
    • Pour chaque stratégie de limite d'accès de compte principal, la réponse affiche les éléments suivants:

      • Indique si la règle autorise ou non l'accès est appliquée.
      • Version d'application de la stratégie. Ce numéro de version détermine si IAM applique stratégie de limite d'accès de compte principal pour l'autorisation demandée. Si le l'autorisation n'est pas appliquée, la règle n'a pas d'incidence sur le fait compte principal peut accéder à la ressource.
      • Les règles de la stratégie de limite d'accès de compte principal et si chaque règle autorise l'accès. Pour chaque règle, la réponse indique si le la ressource interrogé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 répertoriée dans la règle. Resource Manager uniquement les ressources (projets, dossiers et organisations) dans les règles de limite d'accès de compte principal.
        • L'un des ancêtres de la ressource (c'est-à-dire un projet, un dossier ou organisation située au-dessus de la ressource dans la colonne resource hiérarchie) figure dans la règle.

De nombreux objets dans la réponse comportent également un champ relevance. La valeur dans ce indique dans quelle mesure cet objet contribue à l'état d'accès global. Le champ relevance peut avoir les valeurs suivantes:

  • HEURISTIC_RELEVANCE_HIGH: indique que l'objet a un impact important sur le résultat. En d'autres termes, supprimer l'objet modifiera probablement de l'état d'accès. 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 a peu de chances de modifier la l'état d'accès global. Par exemple, une règle de refus qui ne contient pas ou le compte principal aurait cette valeur de pertinence.

REST

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

  • overallAccessState: indique si le compte principal est en mesure d'utiliser le l'autorisation spécifiée pour accéder à la ressource spécifiée en fonction les stratégies d'autorisation, de refus et de limite d'accès de compte principal.

    Les stratégies pertinentes de limite d'accès de compte principal incluent toutes les règles de limite d'accès de compte principal qui sont liés à un ensemble de comptes principaux qui l'inclut.

    Les règles d'autorisation et de refus applicables sont les suivantes:

    • 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

    Stratégies d'autorisation et de refus des projets, dossiers et organisations parents sont pertinentes en raison de l'héritage des règles. 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ès à la ressource, les types de stratégies doivent autoriser l’accès. Pour en savoir plus, consultez la section Évaluation des stratégies.

  • 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ésumé des balises que à la ressource.
  • allowPolicyExplanation: récapitulatif indiquant si la propriété accordent l'autorisation au compte principal, suivie d'une liste et leurs liaisons de rôles.

    Pour chaque stratégie d'autorisation, la réponse répertorie toutes les liaisons de rôles dans la stratégie. 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 imprime ensuite le texte JSON complet de la stratégie d'autorisation.

  • denyPolicyExplanation: un résumé indiquant si le refus concerné Les stratégies refusent l'autorisation au compte principal, suivie d'une liste de ressources à l'aide de stratégies de refus. Pour chaque ressource, la réponse répertorie toutes les stratégies de refus associée à la ressource.

    Pour chaque stratégie de refus, la réponse imprime les métadonnées de la stratégie, répertorie les des règles de refus de la stratégie, puis évalue chaque règle en fonction des critères:

    • Indique si la règle de refus inclut l'autorisation.
    • Indique si l'autorisation est répertoriée en tant qu'exception dans la règle de refus.
    • Indique si la règle de refus inclut le compte principal.
    • Indique si le compte principal est répertorié en tant qu'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 éléments les stratégies de limite d'accès de compte principal lui permettent d'accéder puis des liaisons de stratégie de limite d'accès de compte principal pertinentes de limites d'accès de compte principal.

    Les stratégies de limites d'accès des comptes principaux peuvent autoriser l'accès, mais pas l'autoriser, ou de ne pas être appliquées. Les stratégies de limite d'accès des comptes principaux ne sont pas appliquées dans le situations suivantes:

    Si une règle de limite d'accès de compte principal n'est pas appliquée, cela n'a pas d'incidence le compte principal peut accéder à la ressource.

    La réponse répertorie également toutes les liaisons de stratégie qui incluent le compte principal et les détails de la stratégie de limite d'accès de compte principal dans chacune de ces stratégies de liaison:

    • Pour chaque liaison de stratégie de limite d'accès de compte principal, la réponse indique si la liaison de stratégie est appliquée au compte principal, puis imprime le texte la liaison de stratégie. Une liaison de stratégie est appliquée si le compte principal la liaison inclut le compte principal interrogé, et si la condition dans le La liaison de stratégie prend la valeur true pour le compte principal interrogé. Si la liaison de stratégie n'est pas appliquée, la stratégie n'a pas d'incidence sur l'état le compte principal peut accéder à la ressource.
    • Pour chaque stratégie de limite d'accès de compte principal, la réponse affiche les éléments suivants:

      • Indique si la règle autorise ou non l'accès est appliquée.
      • Version d'application de la stratégie. Ce numéro de version détermine si IAM applique stratégie de limite d'accès de compte principal pour l'autorisation demandée. Si le l'autorisation n'est pas appliquée, la règle n'a pas d'incidence sur le fait compte principal peut accéder à la ressource.
      • Les règles de la stratégie de limite d'accès de compte principal et si chaque règle autorise l'accès. Pour chaque règle, la réponse indique si le la ressource interrogé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 répertoriée dans la règle. Resource Manager uniquement les ressources (projets, dossiers et organisations) dans les règles de limite d'accès de compte principal.
        • L'un des ancêtres de la ressource (c'est-à-dire un projet, un dossier ou organisation située au-dessus de la ressource dans la colonne resource hiérarchie) figure dans la règle.

De nombreux objets dans la réponse comportent également un champ relevance. La valeur dans ce indique dans quelle mesure cet objet contribue à l'état d'accès global. Le champ relevance peut avoir les valeurs suivantes:

  • HEURISTIC_RELEVANCE_HIGH: indique que l'objet a un impact important sur le résultat. En d'autres termes, supprimer l'objet modifiera probablement de l'état d'accès. 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 a peu de chances de modifier la l'état d'accès global. Par exemple, une règle de refus qui ne contient pas ou le compte principal aurait cette valeur de pertinence.

Dépanner des liaisons de rôles conditionnelles

Policy Troubleshooter résout automatiquement le problème des liaisons de rôles et des règles de refus basées sur des tags. Il y a aussi dépanne automatiquement les liaisons de stratégie de limite d'accès de compte principal avec des conditions en fonction des comptes principaux.

Pour résoudre les problèmes liés à d'autres types de liaisons de rôles conditionnelles ou de refus conditionnel, Policy Troubleshooter a besoin d'autres le contexte de la demande. Par exemple, pour dépanner des conditions basées sur de date/heure, Policy Troubleshooter a besoin de l'heure requête.

Vous fournissez ce contexte supplémentaire dans la gcloud CLI et l'API REST. manuellement.

Dans la console Google Cloud, vous pouvez fournir ce contexte supplémentaire le dépannage directement depuis le journal d'audit des activités d'administration ; Journal d'audit des accès aux données. Chaque entrée de journal d'audit correspond à un à un l'API Google Cloud ou une action que Google Cloud effectue au nom de l'utilisateur. Lorsque vous dépannez à partir d'un journal d'audit, Policy Troubleshooter obtient automatiquement des informations supplémentaires sur la demande, comme la date et l'heure, Policy Troubleshooter pour analyser les liaisons de rôles conditionnelles des 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 Google Cloud Console, 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 contenues dans l'entrée de journal pour résoudre les problèmes d'accès, puis affiche les résultats. Le contexte supplémentaire est répertorié dans les détails de l'évaluation sous Contexte de la condition. Pour afficher les 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 sur cette page.

  6. Facultatif: Pour résoudre les problèmes liés à une autre requête impliquant un rôle conditionnel et les règles de refus, revenez à la page de l'explorateur de journaux et répétez l'opération 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 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 les autorisations que vous souhaitez résoudre.
  • RESOURCE: ressource pour laquelle l'autorisation est accordée accordé.
  • PERMISSION: autorisation que vous souhaitez accorder de dépannage.
  • DESTINATION_IP : facultatif. L'adresse IP de destination de la requête à utiliser lors de la vérification des liaisons de rôles conditionnelles. Exemple : 198.1.1.1.
  • DESTINATION_PORT : facultatif. La destination de la requête port à utiliser lors de la vérification des liaisons de rôles conditionnelles. Exemple : "8080".
  • REQUEST_TIME : facultatif. Le code temporel de la requête à utiliser lors de la vérification des liaisons de rôles conditionnelles. Utilisez un code temporel en RFC 3339, par exemple 2099-02-01T00:00:00Z.
  • RESOURCE_NAME : facultatif. La valeur du nom de ressource à à utiliser lors de la vérification des liaisons de rôles conditionnelles. Pour obtenir la liste des ressources acceptées formats de nom, consultez la section Nom de la ressource de sortie.
  • RESOURCE_SERVICE : facultatif. Le service de ressources à utiliser lors de la vérification des liaisons de rôles conditionnelles. Pour obtenir la liste des noms de services, consultez la section Ressources valeurs de service.
  • RESOURCE_TYPE : facultatif. Pour obtenir la liste des types de ressources, consultez la section Type de ressource valeurs.

Exécutez la 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 rôle de liaison et de refus avec une condition, la réponse inclut Champ conditionExplanation décrivant si la condition prend la valeur "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 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 l'API Policy Troubleshooter iam.troubleshoot .

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

  • EMAIL: adresse e-mail du compte principal les autorisations que vous souhaitez résoudre.
  • RESOURCE: ressource pour laquelle l'autorisation est accordée accordé.
  • PERMISSION: autorisation que vous souhaitez accorder de dépannage.
  • DESTINATION_IP : facultatif. L'adresse IP de destination de la requête à utiliser lors de la vérification des liaisons de rôles conditionnelles. Exemple : 198.1.1.1.
  • DESTINATION_PORT : facultatif. La destination de la requête port à utiliser lors de la vérification des liaisons de rôles conditionnelles. Exemple : "8080".
  • REQUEST_TIME : facultatif. Le code temporel de la requête à utiliser lors de la vérification des liaisons de rôles conditionnelles. Utilisez un code temporel en RFC 3339, par exemple 2099-02-01T00:00:00Z.
  • RESOURCE_NAME : facultatif. La valeur du nom de ressource à à utiliser lors de la vérification des liaisons de rôles conditionnelles. Pour obtenir la liste des ressources acceptées formats de nom, consultez la section Nom de la ressource de sortie.
  • RESOURCE_SERVICE : facultatif. Le service de ressources à utiliser lors de la vérification des liaisons de rôles conditionnelles. Pour obtenir la liste des noms de services, consultez la section Ressources valeurs de service.
  • RESOURCE_TYPE : facultatif. Pour obtenir la liste des types de ressources, consultez la section Type de ressource valeurs.

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 rôle de liaison et de refus avec une condition, la réponse inclut Champ conditionExplanation décrivant si la condition prend la valeur "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 service de ressources:

<ph type="x-smartling-placeholder">
</ph>
...
{
  "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
    }]
  }
}
...

Étape suivante