Fehler bei IAM-Berechtigungen beheben

Mit Policy Troubleshooter können Sie nachvollziehen, ob ein Hauptkonto auf eine Ressource zugreifen kann. Mit der Angabe eines Hauptkontos, einer Ressource und einer Berechtigung untersucht Policy Troubleshooter die Zulassungsrichtlinien, Ablehnungsrichtlinien und PAB-Richtlinien (Principal Access Boundary), die sich auf den Zugriff des Hauptkontos auswirken. Anschließend wird angezeigt, ob das Hauptkonto anhand dieser Richtlinien die angegebene Berechtigung für den Zugriff auf die Ressource verwenden kann. Außerdem werden die relevanten Richtlinien aufgeführt und erläutert, wie sie sich auf den Zugriff des Hauptkontos auswirken.

Sie können über dieGoogle Cloud Console, die Google Cloud CLI oder die REST API auf die Richtlinien-Fehlerbehebung zugreifen. Bei einfachen Abfragen ist die Verwendung der Google Cloud Console normalerweise am schnellsten. Bei komplexeren Szenarien sollten Sie die gcloud CLI oder die REST API verwenden.

Hinweis

  • Aktivieren Sie die Policy Troubleshooter API, falls sie noch nicht aktiviert ist.

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen

    API aktivieren

Erforderliche Berechtigungen

Um den Zugriff Ihrer Principals vollständig zu analysieren, benötigen Sie die folgenden Berechtigungen.

Berechtigungen zur Fehlerbehebung beim Zugriff für einzelne Hauptkonten

Policy Troubleshooter analysiert den Zugriff eines Hauptkontos auf eine Ressource anhand der Zulassungsrichtlinien, Ablehnungsrichtlinien, Principal Access Boundary-Richtlinien und Rollen, die Sie ansehen dürfen. Wenn Sie keine Berechtigung zum Aufrufen einer Richtlinie haben, die für eine Ressource gilt, oder wenn Sie keine Berechtigung zum Aufrufen einer benutzerdefinierten Rolle haben, können Sie möglicherweise nicht feststellen, ob ein Hauptkonto Zugriff hat.

Berechtigungen zur Fehlerbehebung bei Zulassungs- und Ablehnungsrichtlinien

Wenn Sie Probleme mit Zulassungs- und Ablehnungsrichtlinien beheben möchten, benötigen Sie Berechtigungen für die Organisation, die die Ressource enthält, für die Sie die Fehlerbehebung durchführen möchten. Mit diesen Berechtigungen können Sie die Zulassungs- und Ablehnungsrichtlinien ansehen, die den Zugriff auf die Ressource steuern.

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für die Organisation zuzuweisen, die die Ressource enthält, für die Sie den Zugriff eines Hauptkontos prüfen möchten:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Wenn Sie nicht berechtigt sind, die Zulassungs- und Ablehnungsrichtlinien für eine Ressource anzusehen, sind die Zugriffsergebnisse für diese Richtlinien Unknown.

Berechtigungen zur Fehlerbehebung bei Principal Access Boundary-Richtlinien

Um Probleme mit Principal Access Boundary-Richtlinien zu beheben, benötigen Sie Berechtigungen für die Organisation, deren Hauptkonto-Set das Hauptkonto enthält. Wie Sie diese Organisation identifizieren, hängt vom Hauptkontotyp ab:

  • Google-Konten und Google-Gruppen: Die Organisation, die mit der Google Workspace-Domain verknüpft ist, die den Prinzipal enthält
  • Föderierte Identitäten (Identitäten in Workforce Identity-Pools oder Workload Identity-Pools): Die Organisation, die den Identitätspool enthält, der den Principal umfasst.
  • Dienstkonten: Die Organisation, die das Projekt enthält, in dem das Dienstkonto erstellt wurde
  • Agent-Identitäten: Die Organisation, die das Projekt enthält, in dem der Agent erstellt wurde

Mit diesen Berechtigungen können Sie die Principal Access Boundary-Richtlinien ansehen, die steuern, worauf das Hauptkonto zugreifen kann.

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für die entsprechende Organisation zuzuweisen, damit Sie die nötigen Berechtigungen für die Fehlerbehebung für den Zugriff eines Hauptkontos haben:

  • Principal Access Boundary-Richtlinie Viewer (roles/iam.principalAccessBoundaryViewer)
  • Fehlerbehebung bei Principal Access Boundary-Richtlinien, die an den Hauptkontosatz eines Projekts, Ordners oder einer Organisation oder an Agent-Identitäten gebunden sind: Organization Administrator (roles/resourcemanager.organizationAdmin)
  • Fehlerbehebung bei Principal Access Boundary-Richtlinien, die an Google Workspace-Domains gebunden sind: Workspace Pool IAM Admin (roles/iam.workspacePoolAdmin)
  • Fehlerbehebung bei Principal Access Boundary-Richtlinien, die an Mitarbeiteridentitätspools gebunden sind: IAM Workforce Pool Admin (roles/iam.workforcePoolAdmin)
  • Fehlerbehebung bei Principal Access Boundary-Richtlinien, die an Workload Identity-Pools gebunden sind: IAM Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Wenn Sie nicht berechtigt sind, die Principal Access Boundary-Richtlinien anzusehen, die für ein Hauptkonto gelten, sind die Zugriffsergebnisse für Principal Access Boundary-Richtlinien Unknown.

Berechtigungen zur Fehlerbehebung beim Zugriff für Gruppenmitglieder

Wenn Ihre „allow“- und „deny“-Richtlinien Gruppen enthalten, benötigen Sie die Google Workspace Admin API-Berechtigung groups.read, um den Zugriff für einzelne Gruppenmitglieder zu analysieren. Super Admins und Gruppenadministratoren haben diese Berechtigung automatisch. Wenn Sie einem Nutzer, der kein Super Admin oder Group Admin ist, diese Berechtigung erteilen möchten, erstellen Sie eine benutzerdefinierte Google Workspace-Administrator-Administratorrolle, die die Berechtigung groups.read enthält (unter Admin API-Berechtigungen) und gewähren Sie sie dem Nutzer.

Wenn Sie diese Berechtigungen nicht haben, haben Rollenbindungen und Ablehnungsregeln, die Gruppen oder Domains enthalten, ein Zugriffsergebnis von Unbekannt, es sei denn, die Rollenbindung oder Ablehnungsregel enthält auch explizit das Hauptkonto.

Berechtigungen zur Fehlerbehebung beim Zugriff für Domainmitglieder

Wenn Ihre Richtlinien zum Zulassen und Ablehnen ein Google Workspace-Konto oder eine Cloud Identity-Domain enthalten, müssen Sie ein Domainadministrator sein, um den Zugriff für einzelne Domainmitglieder zu beheben.

Wenn Sie diese Berechtigungen nicht haben, haben Rollenbindungen und Ablehnungsregeln, die Gruppen oder Domains enthalten, ein Zugriffsergebnis von Unbekannt, es sei denn, die Rollenbindung oder Ablehnungsregel enthält auch explizit das Hauptkonto.

Auf die Fehlerbehebung zugreifen

Zur Fehlerbehebung für den Zugriff benötigen Sie das Hauptkonto, die Ressource und die Berechtigung, die Sie prüfen möchten. Diese Informationen können über eine Fehler-ID bereitgestellt werden:

  • Fehler-ID:Eine eindeutige Kennung für eine Fehlermeldung zu Berechtigungen. Die Fehler-ID enthält Kontextinformationen zum Fehler, einschließlich des Hauptkontos, der Ressource, der Berechtigung und der unterstützten IAM-Bedingungen. Eine Fehler-ID, die sich auf eine Agent Identity bezieht, liefert Kontext für die Agent Identity und ihre Claims, z. B. Plattform und Container.

    Unterstützte IAM-Bedingungen sind principal.type und principal.subject.

Wenn Sie keine Fehler-ID haben, können Sie den Zugriff mit den folgenden Informationen beheben:

  • Hauptkonto:Die zu überprüfende Identität. Sie können einen der folgenden Werte eingeben:

    • Eine E-Mail-Adresse:Muss sich auf einen Nutzer, ein einzelnes Dienstkonto oder eine Gruppe von Dienstkonto-Hauptkonten beziehen.

    • Eine Agent Identity-Kennung muss diesem Format entsprechen: TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH.

      Beispiel: agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent

      Der Policy Troubleshooter extrahiert die Attribute für Plattform und Ressourcencontainer aus dem Betreffstring des Agents mithilfe des Standardmusters resources/{platform}/projects/{project_number}/.... Wenn ein Kundenservicemitarbeiter ein nicht standardmäßiges Betreffformat verwendet, kann Policy Troubleshooter die zugehörigen Attribute nicht ableiten und attributbasierte Bindungen von Hauptkonten werden als Unknown ausgewertet.

      Wenn ein Agent keine Bindungen für die Gewährung von Berechtigungen hat, gibt Policy Troubleshooter den Zugriffsstatus UNKNOWN_INFO anstelle von NOT_GRANTED zurück.

      Die Kennzeichnungen verwenden Folgendes:

      • TRUST_DOMAIN: Die Vertrauensdomäne Ihrer Organisation, z. B. agents.global.org-123456789012.system.id.goog

      • SERVICE: Der Kurzname des Google Cloud-Dienstes (z. B. aiplatform oder discoveryengine)

      • RESOURCE_PATH: Der vollständige Pfad zur Ressource, die den Agent hostet.

    Andere Arten von Hauptkonten, einschließlich Gruppen, Domains, Mitarbeiteridentitäten und Arbeitslastidentitäten, werden nicht unterstützt.

  • Ressource:Der vollständige Name der Ressource, für die Sie den Zugriff prüfen möchten. Wenn Sie beispielsweise den Zugriff auf das Projekt my-project beheben möchten, geben Sie //cloudresourcemanager.googleapis.com/projects/my-project ein. Weitere Ressourcentypen finden Sie in den Beispielen für vollständige Ressourcennamen.

  • Berechtigung: Die zu prüfende Berechtigung. Wenn Sie dieGoogle Cloud Console verwenden, wird während der Eingabe eine Liste mit Vorschlägen angezeigt.

    Damit eine Berechtigung untersucht werden kann, muss sie für die Ressource in der Anfrage gelten. Mit anderen Worten: Es muss möglich sein, mit dieser Berechtigung auf die Ressource zuzugreifen. Wenn die Berechtigung nicht für die Ressource gilt, schlägt die Anfrage fehl. Wenn Sie beispielsweise versuchen, die Berechtigung compute.instances.get für einen Google Kubernetes Engine-Cluster zu beheben, schlägt die Anfrage fehl, da die Berechtigung compute.instance.get nicht für den Zugriff auf Google Kubernetes Engine-Cluster verwendet werden kann.

    Eine vollständige Liste der Berechtigungen finden Sie in der Berechtigungsreferenz.

Console

So beheben Sie Zugriffsprobleme:

  1. Rufen Sie in der Google Cloud Console die Seite Richtlinien-Fehlerbehebung auf.

    Zur Seite „Richtlinien-Fehlerbehebung“

  2. Wenn Sie eine Fehler-ID haben, wählen Sie Fehler-ID aus und geben Sie sie ein.

  3. Wenn Sie keine Fehler-ID haben, wählen Sie Manuell aus.

    1. Geben Sie die E-Mail-Adresse des Hauptkontos oder die Agent Identity-Kennung ein, deren Zugriff Sie prüfen möchten.

    2. Geben Sie den vollständigen Ressourcennamen der zu prüfenden Ressource ein.

      Wenn Sie den vollständigen Ressourcennamen nicht kennen, haben Sie folgende Möglichkeiten:

      • Wenn Sie den Zugriff für ein Projekt, einen Ordner oder eine Organisation beheben möchten, beginnen Sie mit der Eingabe, um Optionen für die automatische Vervollständigung zu sehen.
      • Wenn Sie den Zugriff für einen anderen Ressourcentyp beheben möchten, klicken Sie auf Durchsuchen, um das Dialogfeld für die Ressourcensuche zu öffnen, und suchen Sie dann nach der Ressource:

        1. Wählen Sie im Feld Bereich auswählen ein Projekt, einen Ordner oder eine Organisation aus, in der gesucht werden soll.
        2. Wählen Sie im Feld Ressourcentyp die Ressourcentypen aus, nach denen Sie suchen möchten.
        3. Geben Sie im Feld Nach Ressourcen suchen einen Teil des Ressourcennamens ein.
        4. Wählen Sie im Ergebnisbereich die Ressource aus, die Sie prüfen möchten.
        5. Klicken Sie auf Auswählen, um die Ressource auszuwählen und das Dialogfeld zu schließen.
    3. Geben Sie die zu prüfende Berechtigung ein.

      Wenn Sie den vollständigen Berechtigungsnamen nicht kennen, beginnen Sie mit der Eingabe, um Optionen für die automatische Vervollständigung zu sehen.

    4. Optional: Wählen Sie zum Hinzufügen mehrerer Ressourcen und Berechtigungen Weiteres Paar hinzufügen aus und wiederholen Sie den vorherigen Schritt.

  4. Klicken Sie auf Zugriff prüfen.

gcloud

Mit dem Befehl gcloud beta policy-troubleshoot iam können Sie herausfinden, warum ein Hauptkonto eine IAM-Berechtigung hat oder nicht.

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

  • VERSION: Optional. Die zu verwendende Version des Befehls. Wenn Sie den Zugriff nur anhand von Zulassungs- und Ablehnungsrichtlinien beheben möchten, geben Sie keine Version an. Wenn Sie Zugriffsprobleme auf Grundlage von Zulassungs‑, Ablehnungs‑ und Principal Access Boundary-Richtlinien beheben möchten, verwenden Sie die Version beta.
  • EMAIL: Die E-Mail-Adresse des Hauptkontos, für dessen Berechtigungen Sie eine Fehlerbehebung ausführen möchten. Für eine Agent Identity müssen Sie stattdessen die Prinzipal-ID angeben.
  • RESOURCE: Die Ressource, für die die Berechtigung gewährt wird.
  • PERMISSION: Die Berechtigung, für die Sie eine Fehlerbehebung ausführen möchten.

Führen Sie den Befehl gcloud beta policy-troubleshoot iam aus:

Linux, macOS oder 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

Sie sollten eine Antwort ähnlich der folgenden erhalten:

Antwort

{
  "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

Wenn Sie herausfinden möchten, warum ein Prinzipal eine IAM-Berechtigung hat oder nicht, verwenden Sie die Methode iam.troubleshoot der Policy Troubleshooter API.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • VERSION: Die API-Version, die für diese Anfrage verwendet werden soll. Wenn Sie den Zugriff nur anhand von Zulassungs- und Ablehnungsrichtlinien beheben möchten, verwenden Sie v3. Verwenden Sie v3beta, um den Zugriff auf Grundlage von Zulassungs-, Ablehnungs- und Principal Access Boundary-Richtlinien zu beheben.
  • EMAIL: Die E-Mail-Adresse des Hauptkontos, für dessen Berechtigungen Sie eine Fehlerbehebung ausführen möchten. Für eine Agent Identity müssen Sie stattdessen die Prinzipal-ID angeben.
  • RESOURCE: Die Ressource, für die die Berechtigung gewährt wird.
  • PERMISSION: Die Berechtigung, für die Sie eine Fehlerbehebung ausführen möchten.
  • PROJECT_ID: Die ID des Projekts, das Sie für die Anfrage verwenden möchten. Projekt-IDs sind alphanumerische Strings, wie my-project.

HTTP-Methode und URL:

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

JSON-Text anfordern:

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

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

Ergebnisse des Troubleshooters

Console

Die Ergebnisseite enthält die folgenden Informationen:

Details zur Bewertung

Der Abschnitt Bewertungsdetails enthält eine Zusammenfassung des Zugriffs, bei dem Sie die Fehlerbehebung durchführen, einschließlich des angegebenen Hauptkontos, der Ressource und der Berechtigung. Wenn Sie mehrere Paare aus Ressourcen und Berechtigungen untersuchen, können Sie über die Liste Access Evaluation (Zugriffsbewertung) zwischen ihnen wechseln.

Details zur Richtlinie

Der Bereich Richtliniendetails enthält Details dazu, wie sich die relevanten Zulassungs-, Ablehnungs- und Principal Access Boundary-Richtlinien auf den Zugriff des Hauptkontos auswirken.

Relevante Principal Access Boundary-Richtlinien umfassen alle Principal Access Boundary-Richtlinien, die an einen Hauptkontensatz gebunden sind, der das Hauptkonto enthält.

Relevante Zulassungs- und Ablehnungsrichtlinien umfassen Folgendes:

  • Zulassungsrichtlinie der Ressource
  • Ablehnungsrichtlinien der Ressource, falls vorhanden
  • Die Zulassungsrichtlinien des übergeordneten Projekts, des Ordners und der Organisation der Ressource, sofern vorhanden
  • Ablehnungsrichtlinien des übergeordneten Projekts, des Ordners und der Organisation der Ressource, falls vorhanden

Die Richtlinien zum Zulassen oder Ablehnen von übergeordneten Projekten, Ordnern und Organisationen sind aufgrund der Richtlinienübernahme relevant. Wenn Sie eine Zulassung- oder Ablehnungsrichtlinie an ein Projekt, einen Ordner oder eine Organisation anhängen, gilt diese Richtlinie auch für alle Ressourcen innerhalb dieses Projekts, Ordners oder dieser Organisation.

Wenn eine Ablehnungsrichtlinie für eine Organisation beispielsweise besagt, dass ein Hauptkonto keine bestimmte Berechtigung verwenden kann, kann das Hauptkonto diese Berechtigung nicht für eine Ressource innerhalb der Organisation verwenden. Diese Regel gilt auch dann, wenn die Ordner und Projekte innerhalb dieser Organisation striktere Ablehnungsrichtlinien haben oder Richtlinien zulassen, die dem Hauptkonto die Berechtigung erteilen.

Wenn eine „allow”-Richtlinie für ein Projekt einem Hauptkonto eine bestimmte Berechtigung erteilt, hat das Hauptkonto diese Berechtigung für jede Ressource innerhalb des Projekts, sofern ihm diese Berechtigung nicht verweigert wird.

Der Abschnitt Richtliniendetails enthält die folgenden Abschnitte:

Zugriffsstatus

Im Abschnitt Zugriffsstatus werden die Ergebnisse für jeden Richtlinientyp (Principal Access Boundary-Richtlinien, Ablehnungsrichtlinien und Zulassungsrichtlinien) zusammengefasst und das Gesamtergebnis angegeben. Das Ergebnis gibt an, ob das Hauptkonto die Berechtigung gemäß den relevanten Richtlinien verwenden kann, um auf die Ressource zuzugreifen.

Damit ein Nutzer die Berechtigung zum Zugriff auf die Ressource verwenden kann, muss der Zugriff in allen Richtlinientypen zulässig sein. Weitere Informationen finden Sie unter Richtlinienauswertung.

Principal Access Boundary-Richtlinie

Im Bereich Principal Access Boundary-Richtlinie können Sie alle Principal Access Boundary-Richtlinien sehen, denen das Hauptkonto unterliegt, sowie die Richtlinienbindungen, mit denen diese Richtlinien an das Hauptkonto gebunden sind.

Im Bereich Richtlinien werden alle Richtlinien aufgeführt, die an eine Hauptkontogruppe gebunden sind, die das Hauptkonto enthält. Neben jeder Richtlinie befindet sich ein Symbol, das angibt, wie sich die Richtlinie auf den Zugriff des Hauptkontos auswirkt.

Principal Access Boundary-Richtlinien können den Zugriff eines Hauptkontos auf folgende Weise beeinträchtigen:

  • Hauptkonto darf auf die Ressource zugreifen: Die Principal Access Boundary-Richtlinie gilt für das Hauptkonto und eine der Regeln enthält die abgefragte Ressource.
  • Prinzipal darf nicht auf die Ressource zugreifen: Die Principal Access Boundary-Richtlinie gilt für das Hauptkonto, aber die abgefragte Ressource ist nicht in den Regeln dieser Richtlinie enthalten.
  • Nicht erzwungen: Principal Access Boundary-Richtlinien werden in den folgenden Situationen nicht erzwungen:

    • IAM erzwingt die angegebene Berechtigung nicht in der Erzwingungsversion der Principal Access Boundary-Richtlinie. Daher kann die Principal Access Boundary-Richtlinie den Zugriff nicht blockieren.
    • Aufgrund einer Bedingung in der Richtlinienbindung gilt die Richtlinie oder Bindung zur Begrenzung des Hauptkontozugriffs nicht für das Hauptkonto.
    • Eine Principal Access Boundary-Richtlinie hat keine Regeln.

    Wenn eine Principal Access Boundary-Richtlinie nicht erzwungen wird, kann sie sich nicht darauf auswirken, ob das Hauptkonto auf die Ressource zugreifen kann.

Wenn Sie die Regeln und Bindungen aufrufen möchten, die mit einer Principal Access Boundary-Richtlinie verknüpft sind, klicken Sie auf den Richtliniennamen. Im Bereich neben Richtlinien werden die Details der Richtlinie angezeigt.

Klicken Sie auf den Tab Grenzregeln, um die Regeln in der Richtlinie aufzurufen. Auf diesem Tab wird eine Tabelle mit den relevanten Regeln für die Principal Access Boundary-Richtlinie angezeigt.

Eine Principal Access Boundary-Regel ist relevant, wenn sie sich auf das Gesamtergebnis der Policy Troubleshooter-Abfrage auswirkt. Daher variieren die relevanten Regeln je nach den Ergebnissen des Policy Troubleshooters. Hier einige Beispiele:

  • Policy Troubleshooter gibt an, dass der Prinzipal auf die Ressource zugreifen kann. Daher sind die relevanten Regeln diejenigen, die dem Hauptkonto den Zugriff auf die Ressource ermöglichen.
  • Policy Troubleshooter gibt an, dass der Prinzipal nicht auf die Ressource zugreifen kann. Gemäß den relevanten Principal Access Boundary-Richtlinien darf das Hauptkonto jedoch auf die Ressource zugreifen. Daher sind keine Regeln relevant, weil die Principal Access Boundary-Richtlinien nicht der Grund dafür sind, dass das Hauptkonto nicht auf die Ressource zugreifen kann.
  • Policy Troubleshooter gibt an, dass der Prinzipal nicht auf die Ressource zugreifen kann. Außerdem darf das Hauptkonto gemäß den relevanten Principal Access Boundary-Richtlinien nicht auf die Ressource zugreifen. Daher sind die relevanten Regeln diejenigen, die dem Hauptkonto keinen Zugriff auf die Ressource gewähren.

Wenn Sie alle Regeln zur Begrenzung des Hauptkontozugriffs in einer Richtlinie sehen möchten, entfernen Sie das Häkchen neben Nur relevante Regeln und Bindungen anzeigen.

Die Spalte Ergebnisse in der Tabelle mit den Begrenzungsregeln gibt an, ob die Principal Access Boundary-Regel die abgefragte Ressource enthält. Wenn Sie weitere Details zur Regel aufrufen möchten, klicken Sie auf Regeldetails ansehen.

Klicken Sie auf den Tab Bindungen, um die Richtlinienbindungen für die Richtlinie aufzurufen. Auf diesem Tab wird eine Tabelle mit den relevanten Richtlinienbindungen für die ausgewählte Principal Access Boundary-Richtlinie angezeigt.

Eine Richtlinienbindung ist relevant, wenn die Principal Access Boundary-Richtlinie tatsächlich auf das abgefragte Hauptkonto angewendet wird. Damit eine Richtlinienbindung eine Principal Access Boundary-Richtlinie auf ein Hauptkonto anwenden kann, muss Folgendes zutreffen:

  • Die in der Richtlinienbindung festgelegte Hauptkontogruppe muss das abgefragte Hauptkonto enthalten.
  • Alle Bedingungen in der Richtlinienbindung müssen für den abgefragten Prinzipal als true ausgewertet werden.

Wenn Sie alle Richtlinienbindungen mit Prinzipalgruppen sehen möchten, die das abgefragte Hauptkonto enthalten, unabhängig davon, ob das abgefragte Hauptkonto die Bedingung in der Bindung erfüllt, deaktivieren Sie das Kästchen Nur relevante Regeln und Bindungen anzeigen.

Für Agent Identities (Agentenidentitäten) wertet Policy Troubleshooter Principal Access Boundary-Richtlinien aus, die mit der Ressourcenhierarchie des Hostingprojekts oder -containers des Agents verknüpft sind, und Bedingungen, die mit dem Identitätstyp (principal.type == 'iam.googleapis.com/AgentPoolIdentity') und dem Subjektmuster (principal.subject.startsWith(...)) des Agents übereinstimmen.

Die Spalte Ergebnisse in der Tabelle mit Bindungen gibt an, ob die Bindung für das abgefragte Hauptkonto erzwungen wird. Wenn Sie weitere Informationen zur Richtlinienbindung aufrufen möchten, klicken Sie auf Bindungsdetails ansehen.

Ablehnungsrichtlinie

Im Bereich Ablehnungsrichtlinie können Sie alle relevanten Ablehnungsrichtlinien aufrufen, Ablehnungsregeln identifizieren, die den Zugriff auf das Hauptkonto verweigern, und nachvollziehen, warum eine Ablehnungsregel dem Hauptkonto die Berechtigung verweigert oder nicht verweigert.

Im Bereich Ressourcen mit Ablehnungsrichtlinien werden alle relevanten Ablehnungsrichtlinien aufgelistet, sortiert nach den Ressourcen, mit denen sie verknüpft sind. Neben jeder Ablehnungsrichtlinie befindet sich eine Zugriffsüberprüfung. Diese Auswertung gilt nur für diese Ablehnungsrichtlinie. Sie spiegelt keinen Zugriff durch übernommene Richtlinien wider. Wenn Sie keine Berechtigung zum Aufrufen der Ablehnungsrichtlinie einer Ressource haben, wird die Ressource oder ihre Ablehnungsrichtlinien nicht in der Ressourcenliste aufgeführt.

Wenn Sie die entsprechenden Ablehnungsregeln in diesen Ablehnungsrichtlinien aufrufen möchten, klicken Sie auf eine Ablehnungsrichtlinie. Wenn Sie alle Ablehnungsregeln in den Ablehnungsrichtlinien einer Ressource ansehen möchten, klicken Sie auf eine Ressource. Die Ablehnungsregeln werden im Bereich Ablehnungsregeln angezeigt. Dieser Bereich enthält eine Tabelle mit allen Ablehnungsregeln mit dem abgefragten Hauptkonto oder der Berechtigung für die ausgewählte Ressource oder Ablehnungsrichtlinie.

In der Spalte Zugriff wird angegeben, ob die Ablehnungsregel dem Hauptkonto die Berechtigung verweigert. Wenn Sie weitere Details zur Ablehnungsregel aufrufen möchten, klicken Sie in der entsprechenden Zeile auf Ablehnungsregel ansehen.

Zulassungsrichtlinie

Im Bereich Zulassungsrichtlinie können Sie alle relevanten Zulassungsrichtlinien durchgehen, Rollenbindungen identifizieren, die dem Hauptkonto Zugriff gewähren, und nachvollziehen, warum eine Rollenbindung dem Hauptkonto die Berechtigung gewährt oder nicht.

Im Bereich Ressourcen werden die angegebene Ressource und ihre übergeordneten Elemente aufgeführt. Neben jeder Ressource befindet sich eine Zugriffsbewertung. Diese Auswertung gilt nur für die Zulassungsrichtlinie der jeweiligen Ressource und spiegelt keinen Zugriff durch übernommene Richtlinien wider. Wenn Sie keine Berechtigung zum Aufrufen der Zulassungsrichtlinie einer Ressource haben, ist die Ressource nicht in der Ressourcenliste enthalten.

Wenn Sie die relevanten Rollenbindungen in der „allow“-Richtlinie einer Ressource aufrufen und sehen möchten, ob sie dem Hauptkonto die Berechtigung erteilen, klicken Sie auf die Ressource. Die Rollenbindungen der Zulassungsrichtlinie werden im Bereich Rollenbindungen angezeigt.

Der Bereich Rollenbindungen enthält eine Tabelle mit Rollenbindungen in der Zulassungsrichtlinie der ausgewählten Ressource. Standardmäßig enthält die Tabelle nur Rollenbindungen, die eine Rolle mit der angegebenen Berechtigung enthalten. Wenn das Hauptkonto keinen Zugriff hat, werden in der Tabelle auch Rollenbindungen mit bearbeitbaren benutzerdefinierten Rollen angezeigt. Wenn Sie alle Rollenbindungen sehen möchten, entfernen Sie das Häkchen bei Nur relevante Bindungen einblenden.

In der Spalte Zugriff wird angegeben, ob die Rollenbindung dem Hauptkonto die Berechtigung gewährt. Wenn Sie weitere Details zur Rollenbindung aufrufen möchten, klicken Sie in der Zeile der entsprechenden Rollenbindung auf Bindungsdetails ansehen.

Bei der Auswertung von Zulassungsrichtlinien für Agentenidentitäten prüft der Policy Troubleshooter, ob der Agent mit einer der folgenden Hauptkonto-IDs übereinstimmt:

Prinzipal-ID Beispiel
Direkte Agentenidentitäten principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH
Hauptkontogruppen für Trust-Domains principalSet://TRUST_DOMAIN/*
Hauptkontogruppen für Plattformen principalSet://TRUST_DOMAIN/attribute.platform/SERVICE
Hauptkontogruppen für Ressourcencontainer principalSet://TRUST_DOMAIN/attribute.container/projects/PROJECT_NUMBER
Hauptkontogruppen für Plattformcontainer principalSet://TRUST_DOMAIN/attribute.platformContainer/SERVICE/projects/PROJECT_NUMBER

Wenn Sie den Zugriff für ein Nicht-Agent-Hauptkonto, z. B. ein Nutzer- oder Dienstkonto, untersuchen, werden alle Rollenbindungen für Agent-Identitäten als Not matched ausgewertet.

gcloud

Die Antwort enthält vier Hauptabschnitte: eine Beschreibung des Zugriffstupels in der Anfrage, die Ergebnisse der Auswertung der Zulassungsrichtlinie, die Ergebnisse der Auswertung der Ablehnungsrichtlinie und den allgemeinen Zugriffsstatus.

  • accessTuple: Eine Beschreibung des Zugriffstupels in der Anfrage, einschließlich aller von Ihnen angegebenen Bedingungskontexte. Dieser Abschnitt enthält auch eine Zusammenfassung der Tags, die auf die Ressource angewendet werden.
  • allowPolicyExplanation: Eine Zusammenfassung, ob die relevanten Zulassungsrichtlinien dem Hauptkonto die Berechtigung gewähren, gefolgt von einer Liste der Zulassungsrichtlinien und ihrer Rollenbindungen.

    Für jede Zulassungsrichtlinie werden in der Antwort alle Rollenbindungen in der Richtlinie aufgeführt und anhand der folgenden Kriterien bewertet:

    • Gibt an, ob die Rollenbindung die Berechtigung enthält.
    • Gibt an, ob die Rollenbindung das Hauptkonto enthält.
    • Gibt an, ob die Bedingungen in der Rollenbindung erfüllt sind.

    Anschließend wird der vollständige JSON-Text der Zulassungsrichtlinie in der Antwort ausgegeben.

  • denyPolicyExplanation: Eine Zusammenfassung, ob die relevanten Ablehnungsrichtlinien dem Hauptkonto die Berechtigung verweigern, gefolgt von einer Liste der Ressourcen mit Ablehnungsrichtlinien. Für jede Ressource werden in der Antwort alle Ablehnungsrichtlinien aufgeführt, die mit der Ressource verknüpft sind.

    Für jede Ablehnungsrichtlinie werden in der Antwort die Metadaten der Richtlinie ausgegeben, die Ablehnungsregeln in der Richtlinie aufgeführt und jede Regel anhand der folgenden Kriterien ausgewertet:

    • Gibt an, ob die Ablehnungsregel die Berechtigung enthält.
    • Gibt an, ob die Berechtigung in der Ablehnungsregel als Ausnahme aufgeführt ist.
    • Gibt an, ob die Ablehnungsregel das Hauptkonto enthält.
    • Gibt an, ob das Hauptkonto in der Ablehnungsregel als Ausnahme aufgeführt ist.
    • Gibt an, ob die Bedingungen in der Ablehnungsregel erfüllt sind (falls vorhanden).
  • overallAccessState: Gibt an, ob das Hauptkonto die angegebene Berechtigung verwenden kann, um auf die angegebene Ressource zuzugreifen. Dies hängt von den relevanten Zulassungsrichtlinien, Ablehnungsrichtlinien und Principal Access Boundary-Richtlinien ab.

    Relevante Principal Access Boundary-Richtlinien umfassen alle Principal Access Boundary-Richtlinien, die an einen Hauptkontensatz gebunden sind, der das Hauptkonto enthält.

    Relevante Zulassungs- und Ablehnungsrichtlinien umfassen Folgendes:

    • Zulassungsrichtlinie der Ressource
    • Ablehnungsrichtlinien der Ressource, falls vorhanden
    • Die Zulassungsrichtlinien des übergeordneten Projekts, des Ordners und der Organisation der Ressource, sofern vorhanden
    • Ablehnungsrichtlinien des übergeordneten Projekts, des Ordners und der Organisation der Ressource, falls vorhanden

    Die Richtlinien zum Zulassen oder Ablehnen von übergeordneten Projekten, Ordnern und Organisationen sind aufgrund der Richtlinienübernahme relevant. Wenn Sie eine Zulassung- oder Ablehnungsrichtlinie an ein Projekt, einen Ordner oder eine Organisation anhängen, gilt diese Richtlinie auch für alle Ressourcen innerhalb dieses Projekts, Ordners oder dieser Organisation.

    Wenn eine Ablehnungsrichtlinie für eine Organisation beispielsweise besagt, dass ein Hauptkonto keine bestimmte Berechtigung verwenden kann, kann das Hauptkonto diese Berechtigung nicht für eine Ressource innerhalb der Organisation verwenden. Diese Regel gilt auch dann, wenn die Ordner und Projekte innerhalb dieser Organisation striktere Ablehnungsrichtlinien haben oder Richtlinien zulassen, die dem Hauptkonto die Berechtigung erteilen.

    Wenn eine „allow”-Richtlinie für ein Projekt einem Hauptkonto eine bestimmte Berechtigung erteilt, hat das Hauptkonto diese Berechtigung für jede Ressource innerhalb des Projekts, sofern ihm diese Berechtigung nicht verweigert wird.

    Damit ein Nutzer die Berechtigung für den Zugriff auf die Ressource verwenden kann, muss der Zugriff für alle Richtlinientypen zulässig sein. Weitere Informationen finden Sie unter Richtlinienauswertung.

  • pabPolicyExplanation: Eine Zusammenfassung, ob die relevanten Principal Access Boundary-Richtlinien dem Hauptkonto den Zugriff auf die Ressource erlauben, gefolgt von den relevanten Principal Access Boundary-Richtlinienbindungen und Principal Access Boundary-Richtlinien.

    Principal Access Boundary-Richtlinien können den Zugriff zulassen, nicht zulassen oder nicht erzwungen werden. Principal Access Boundary-Richtlinien werden in den folgenden Situationen nicht erzwungen:

    • IAM erzwingt die angegebene Berechtigung nicht in der Erzwingungsversion der Principal Access Boundary-Richtlinie. Daher kann die Principal Access Boundary-Richtlinie den Zugriff nicht blockieren.
    • Aufgrund einer Bedingung in der Richtlinienbindung gilt die Richtlinie oder Bindung zur Begrenzung des Hauptkontozugriffs nicht für das Hauptkonto.
    • Eine Principal Access Boundary-Richtlinie hat keine Regeln.

    Wenn eine Principal Access Boundary-Richtlinie nicht erzwungen wird, kann sie sich nicht darauf auswirken, ob das Hauptkonto auf die Ressource zugreifen kann.

    In der Antwort werden auch alle Richtlinienbindungen aufgeführt, die das Hauptkonto enthalten, sowie die Details der Principal Access Boundary-Richtlinie in jeder dieser Richtlinienbindungen:

    • Für jede Bindung für Principal Access Boundary-Richtlinien wird in der Antwort ausgegeben, ob die Richtlinienbindung für das Hauptkonto erzwungen wird, gefolgt vom Text der Richtlinienbindung. Eine Richtlinienbindung wird erzwungen, wenn der Hauptkontosatz in der Bindung das abgefragte Hauptkonto enthält und die Bedingung in der Richtlinienbindung für das abgefragte Hauptkonto als true ausgewertet wird. Wenn die Richtlinienbindung nicht erzwungen wird, kann die Richtlinie nicht beeinflussen, ob das Hauptkonto auf die Ressource zugreifen kann.
    • Für jede Principal Access Boundary-Richtlinie wird in der Antwort Folgendes ausgegeben:

      • Gibt an, ob die Richtlinie Zugriff zulässt, keinen Zugriff zulässt oder nicht erzwungen wird.
      • Die Version der Richtlinie, die durchgesetzt wird. Diese Versionsnummer bestimmt, ob IAM diese Principal Access Boundary-Richtlinie für die abgefragte Berechtigung erzwingt. Wenn die Berechtigung nicht erzwungen wird, kann sich die Richtlinie nicht darauf auswirken, ob das Hauptkonto auf die Ressource zugreifen kann.
      • Die Regeln in der Principal Access Boundary-Richtlinie und ob jede Regel den Zugriff zulässt. Für jede Regel wird in der Antwort angegeben, ob die abgefragte Ressource in der Regel enthalten ist.

        Eine Ressource ist in einer Regel enthalten, wenn eine der folgenden Bedingungen zutrifft:

        • Die Ressource ist in der Regel aufgeführt. Nur Resource Manager-Ressourcen (Projekte, Ordner und Organisationen) können direkt in Principal Access Boundary-Regeln aufgeführt werden.
        • Einer der Vorfahren der Ressource (d. h. ein Projekt, ein Ordner oder eine Organisation über der Ressource in der Ressourcenhierarchie) ist in der Regel aufgeführt.

Viele Objekte in der Antwort haben auch ein relevance-Feld. Der Wert in diesem Feld gibt an, wie viel dieses Objekt zum gesamten Zugriffsstatus beiträgt. Das Feld relevance kann die folgenden Werte haben:

  • HEURISTIC_RELEVANCE_HIGH: Gibt an, dass das Objekt einen starken Einfluss auf das Ergebnis hat. Das Entfernen des Objekts ändert also wahrscheinlich den allgemeinen Zugriffsstatus. Eine Rollenbindung, die dem Hauptkonto die angegebene Berechtigung gewährt, hätte beispielsweise diesen Relevanzwert.

  • HEURISTIC_RELEVANCE_NORMAL: Gibt an, dass das Objekt nur einen geringen Einfluss auf das Ergebnis hat. Das Entfernen des Objekts wird den allgemeinen Zugriffsstatus also wahrscheinlich nicht ändern. Das ist beispielsweise bei einer Ablehnungsregel der Fall, die nicht die Berechtigung oder das Hauptkonto enthält.

REST

Die Antwort enthält vier Hauptabschnitte: den allgemeinen Zugriffsstatus, eine Beschreibung des Zugriffstupels in der Anfrage, die Ergebnisse der Auswertung der Zulassungsrichtlinie und die Ergebnisse der Auswertung der Ablehnungsrichtlinie.

  • overallAccessState: Gibt an, ob das Hauptkonto die angegebene Berechtigung verwenden kann, um auf die angegebene Ressource zuzugreifen. Dies hängt von den relevanten Zulassungsrichtlinien, Ablehnungsrichtlinien und Principal Access Boundary-Richtlinien ab.

    Relevante Principal Access Boundary-Richtlinien umfassen alle Principal Access Boundary-Richtlinien, die an einen Hauptkontensatz gebunden sind, der das Hauptkonto enthält.

    Relevante Zulassungs- und Ablehnungsrichtlinien umfassen Folgendes:

    • Zulassungsrichtlinie der Ressource
    • Ablehnungsrichtlinien der Ressource, falls vorhanden
    • Die Zulassungsrichtlinien des übergeordneten Projekts, des Ordners und der Organisation der Ressource, sofern vorhanden
    • Ablehnungsrichtlinien des übergeordneten Projekts, des Ordners und der Organisation der Ressource, falls vorhanden

    Die Richtlinien zum Zulassen oder Ablehnen von übergeordneten Projekten, Ordnern und Organisationen sind aufgrund der Richtlinienübernahme relevant. Wenn Sie eine Zulassung- oder Ablehnungsrichtlinie an ein Projekt, einen Ordner oder eine Organisation anhängen, gilt diese Richtlinie auch für alle Ressourcen innerhalb dieses Projekts, Ordners oder dieser Organisation.

    Wenn eine Ablehnungsrichtlinie für eine Organisation beispielsweise besagt, dass ein Hauptkonto keine bestimmte Berechtigung verwenden kann, kann das Hauptkonto diese Berechtigung nicht für eine Ressource innerhalb der Organisation verwenden. Diese Regel gilt auch dann, wenn die Ordner und Projekte innerhalb dieser Organisation striktere Ablehnungsrichtlinien haben oder Richtlinien zulassen, die dem Hauptkonto die Berechtigung erteilen.

    Wenn eine „allow”-Richtlinie für ein Projekt einem Hauptkonto eine bestimmte Berechtigung erteilt, hat das Hauptkonto diese Berechtigung für jede Ressource innerhalb des Projekts, sofern ihm diese Berechtigung nicht verweigert wird.

    Damit ein Nutzer die Berechtigung für den Zugriff auf die Ressource verwenden kann, muss der Zugriff für alle Richtlinientypen zulässig sein. Weitere Informationen finden Sie unter Richtlinienauswertung.

  • accessTuple: Eine Beschreibung des Zugriffstupels in der Anfrage, einschließlich aller von Ihnen angegebenen Bedingungskontexte. Dieser Abschnitt enthält auch eine Zusammenfassung der Tags, die auf die Ressource angewendet werden.
  • allowPolicyExplanation: Eine Zusammenfassung, ob die relevanten Zulassungsrichtlinien dem Hauptkonto die Berechtigung gewähren, gefolgt von einer Liste der Zulassungsrichtlinien und ihrer Rollenbindungen.

    Für jede Zulassungsrichtlinie werden in der Antwort alle Rollenbindungen in der Richtlinie aufgeführt und anhand der folgenden Kriterien bewertet:

    • Gibt an, ob die Rollenbindung die Berechtigung enthält.
    • Gibt an, ob die Rollenbindung das Hauptkonto enthält.
    • Gibt an, ob die Bedingungen in der Rollenbindung erfüllt sind.

    Anschließend wird der vollständige JSON-Text der Zulassungsrichtlinie in der Antwort ausgegeben.

  • denyPolicyExplanation: Eine Zusammenfassung, ob die relevanten Ablehnungsrichtlinien dem Hauptkonto die Berechtigung verweigern, gefolgt von einer Liste der Ressourcen mit Ablehnungsrichtlinien. Für jede Ressource werden in der Antwort alle Ablehnungsrichtlinien aufgeführt, die mit der Ressource verknüpft sind.

    Für jede Ablehnungsrichtlinie werden in der Antwort die Metadaten der Richtlinie ausgegeben, die Ablehnungsregeln in der Richtlinie aufgeführt und jede Regel anhand der folgenden Kriterien ausgewertet:

    • Gibt an, ob die Ablehnungsregel die Berechtigung enthält.
    • Gibt an, ob die Berechtigung in der Ablehnungsregel als Ausnahme aufgeführt ist.
    • Gibt an, ob die Ablehnungsregel das Hauptkonto enthält.
    • Gibt an, ob das Hauptkonto in der Ablehnungsregel als Ausnahme aufgeführt ist.
    • Gibt an, ob die Bedingungen in der Ablehnungsregel erfüllt sind (falls vorhanden).
  • pabPolicyExplanation: Eine Zusammenfassung, ob die relevanten Principal Access Boundary-Richtlinien dem Hauptkonto den Zugriff auf die Ressource erlauben, gefolgt von den relevanten Principal Access Boundary-Richtlinienbindungen und Principal Access Boundary-Richtlinien.

    Principal Access Boundary-Richtlinien können den Zugriff zulassen, nicht zulassen oder nicht erzwungen werden. Principal Access Boundary-Richtlinien werden in den folgenden Situationen nicht erzwungen:

    • IAM erzwingt die angegebene Berechtigung nicht in der Erzwingungsversion der Principal Access Boundary-Richtlinie. Daher kann die Principal Access Boundary-Richtlinie den Zugriff nicht blockieren.
    • Aufgrund einer Bedingung in der Richtlinienbindung gilt die Richtlinie oder Bindung zur Begrenzung des Hauptkontozugriffs nicht für das Hauptkonto.
    • Eine Principal Access Boundary-Richtlinie hat keine Regeln.

    Wenn eine Principal Access Boundary-Richtlinie nicht erzwungen wird, kann sie sich nicht darauf auswirken, ob das Hauptkonto auf die Ressource zugreifen kann.

    In der Antwort werden auch alle Richtlinienbindungen aufgeführt, die das Hauptkonto enthalten, sowie die Details der Principal Access Boundary-Richtlinie in jeder dieser Richtlinienbindungen:

    • Für jede Bindung für Principal Access Boundary-Richtlinien wird in der Antwort ausgegeben, ob die Richtlinienbindung für das Hauptkonto erzwungen wird, gefolgt vom Text der Richtlinienbindung. Eine Richtlinienbindung wird erzwungen, wenn der Hauptkontosatz in der Bindung das abgefragte Hauptkonto enthält und die Bedingung in der Richtlinienbindung für das abgefragte Hauptkonto als true ausgewertet wird. Wenn die Richtlinienbindung nicht erzwungen wird, kann die Richtlinie nicht beeinflussen, ob das Hauptkonto auf die Ressource zugreifen kann.
    • Für jede Principal Access Boundary-Richtlinie wird in der Antwort Folgendes ausgegeben:

      • Gibt an, ob die Richtlinie Zugriff zulässt, keinen Zugriff zulässt oder nicht erzwungen wird.
      • Die Version der Richtlinie, die durchgesetzt wird. Diese Versionsnummer bestimmt, ob IAM diese Principal Access Boundary-Richtlinie für die abgefragte Berechtigung erzwingt. Wenn die Berechtigung nicht erzwungen wird, kann sich die Richtlinie nicht darauf auswirken, ob das Hauptkonto auf die Ressource zugreifen kann.
      • Die Regeln in der Principal Access Boundary-Richtlinie und ob jede Regel den Zugriff zulässt. Für jede Regel wird in der Antwort angegeben, ob die abgefragte Ressource in der Regel enthalten ist.

        Eine Ressource ist in einer Regel enthalten, wenn eine der folgenden Bedingungen zutrifft:

        • Die Ressource ist in der Regel aufgeführt. Nur Resource Manager-Ressourcen (Projekte, Ordner und Organisationen) können direkt in Principal Access Boundary-Regeln aufgeführt werden.
        • Einer der Vorfahren der Ressource (d. h. ein Projekt, ein Ordner oder eine Organisation über der Ressource in der Ressourcenhierarchie) ist in der Regel aufgeführt.

Viele Objekte in der Antwort haben auch ein relevance-Feld. Der Wert in diesem Feld gibt an, wie viel dieses Objekt zum gesamten Zugriffsstatus beiträgt. Das Feld relevance kann die folgenden Werte haben:

  • HEURISTIC_RELEVANCE_HIGH: Gibt an, dass das Objekt einen starken Einfluss auf das Ergebnis hat. Das Entfernen des Objekts ändert also wahrscheinlich den allgemeinen Zugriffsstatus. Eine Rollenbindung, die dem Hauptkonto die angegebene Berechtigung gewährt, hätte beispielsweise diesen Relevanzwert.

  • HEURISTIC_RELEVANCE_NORMAL: Gibt an, dass das Objekt nur einen geringen Einfluss auf das Ergebnis hat. Das Entfernen des Objekts wird den allgemeinen Zugriffsstatus also wahrscheinlich nicht ändern. Das ist beispielsweise bei einer Ablehnungsregel der Fall, die nicht die Berechtigung oder das Hauptkonto enthält.

Fehlerbehebung bei bedingten Rollenbindungen

Mit dem Policy Troubleshooter werden bedingte Rollenbindungen und Ablehnungsregeln automatisch anhand von Tags analysiert. Außerdem werden Bindungen von Principal Access Boundary-Richtlinien mit Bedingungen basierend auf Hauptkonten automatisch behoben.

Wenn Sie andere Arten von bedingten Rollenbindungen oder bedingten Ablehnungsregeln beheben möchten, benötigt der Policy Troubleshooter zusätzlichen Kontext zur Anfrage. Wenn Sie beispielsweise Fehler bei Bedingungen beheben möchten, die auf Datums-/Zeitattributen basieren, benötigt der Policy Troubleshooter die Uhrzeit der Anfrage.

In der gcloud CLI und der REST API geben Sie diesen zusätzlichen Kontext manuell an.

In der Google Cloud -Konsole können Sie diesen zusätzlichen Kontext bereitstellen, indem Sie direkt über ein beliebiges Audit-Log zur Administratoraktivität oder Audit-Log zum Datenzugriff Fehler beheben. Jeder Audit-Log-Eintrag entspricht einer Anfrage an eineGoogle Cloud API oder einer Aktion, die Google Cloud in Ihrem Namen ausführt. Wenn Sie die Fehlerbehebung über ein Audit-Log vornehmen, ruft der Policy Troubleshooter automatisch zusätzliche Informationen zur Anfrage ab, z. B. Datum und Uhrzeit. So kann er bedingte Rollenbindungen und Ablehnungsregeln analysieren.

Console

So beheben Sie Fehler in bedingten Rollenbindungen und Ablehnungsregeln:

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

    Zum Log-Explorer

  2. Wenn der Seitentitel Legacy-Loganzeige lautet, klicken Sie auf das Drop-down-Menü Upgrade und wählen Sie Upgrade auf den neuen Log-Explorer durchführen aus.

  3. Wenn Sie nur Audit-Logs für Administratoraktivitäten und Datenzugriff ansehen möchten, geben Sie im Query Builder die folgende Abfrage ein und klicken Sie dann auf Abfrage ausführen:

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

    Ersetzen Sie die folgenden Werte:

    • RESOURCE_TYPE: Der Ressourcentyp, für den Sie Audit-Logs auflisten möchten. Verwenden Sie projects, folders oder organizations.
    • RESOURCE_ID: Die ID Ihrer Ressource.
  4. Suchen Sie den Audit-Logeintrag, der der Anfrage entspricht, die Sie beheben möchten. Informationen zum Suchen bestimmter Logeinträge mit dem Log-Explorer finden Sie unter Log-Explorer verwenden.

  5. Klicken Sie in der Spalte Zusammenfassung des Logeintrags auf IAM und dann auf Zugriffsproblem beheben.

    Die Richtlinien-Fehlerbehebung verwendet die Informationen im Logeintrag, um den Zugriff zu analysieren, und zeigt Ihnen dann die Ergebnisse an. Der zusätzliche Kontext wird in den Auswertungsdetails unter Kontext der Bedingung aufgeführt. Wenn Sie die Kontextdetails aufrufen möchten, klicken Sie auf Bedingungskontext ansehen. Weitere Informationen zur Ergebnisseite von Policy Troubleshooter finden Sie auf dieser Seite unter Ergebnisse von Policy Troubleshooter verstehen.

  6. Optional: Wenn Sie ein anderes Problem mit bedingten Rollenbindungen und Ablehnungsregeln beheben möchten, kehren Sie zur Seite „Log-Explorer“ zurück und wiederholen Sie die vorherigen Schritte.

gcloud

Verwenden Sie den Befehl gcloud policy-troubleshoot iam, um Fehler in bedingten Rollenbindungen und Ablehnungsregeln zu beheben.

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

  • EMAIL: Die E-Mail-Adresse des Hauptkontos, für dessen Berechtigungen Sie eine Fehlerbehebung ausführen möchten. Für eine Agent Identity müssen Sie stattdessen die Prinzipal-ID angeben.
  • RESOURCE: Die Ressource, für die die Berechtigung gewährt wird.
  • PERMISSION: Die Berechtigung, für die Sie eine Fehlerbehebung durchführen möchten.
  • DESTINATION_IP: Optional. Die IP-Adresse des Anforderungsziels, die beim Prüfen bedingter Rollenbindungen verwendet werden soll. Beispiel: 198.1.1.1.
  • DESTINATION_PORT: Optional. Der Zielport der Anfrage, der beim Prüfen bedingter Rollenbindungen verwendet werden soll. Beispiel: `8080`.
  • REQUEST_TIME: Optional. Der Zeitstempel der Anfrage, der beim Prüfen bedingter Rollenbindungen verwendet werden soll. Verwenden Sie einen Zeitstempel im RFC 3339-Format, z. B. 2099-02-01T00:00:00Z.
  • RESOURCE_NAME: Optional. Der Ressourcenname, der beim Prüfen bedingter Rollenbindungen verwendet werden soll. Eine Liste der zulässigen Formate für Ressourcennamen finden Sie unter Format der Ressourcennamen.
  • RESOURCE_SERVICE: Optional. Der Wert des Ressourcendienstes, der beim Prüfen bedingter Rollenbindungen verwendet werden soll. Eine Liste der akzeptierten Dienstnamen finden Sie unter Werte für Ressourcendienste.
  • RESOURCE_TYPE: Optional. Eine Liste der akzeptierten Ressourcentypen finden Sie unter Werte für Ressourcentypen.

Führen Sie den Befehl gcloud policy-troubleshoot iam aus:

Linux, macOS oder 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

Die Antwort enthält eine Erklärung des Zugriffs des Auftraggebers. Für jede Rollenbindung und jede Ablehnungsregel mit einer Bedingung enthält die Antwort ein conditionExplanation-Feld, das beschreibt, ob die Bedingung basierend auf dem von Ihnen angegebenen Bedingungskontext als „true“ oder „false“ ausgewertet wird.

Das folgende Beispiel zeigt die Auswertung einer Rollenbindung mit einer Bedingung, die den Ressourcentyp und den Ressourcendienst angibt:

Antwort

...
{
  "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

Verwenden Sie die Methode iam.troubleshoot der Policy Troubleshooter API, um Fehler in bedingten Rollenbindungen und Ablehnungsregeln zu beheben.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • EMAIL: Die E-Mail-Adresse des Hauptkontos, für dessen Berechtigungen Sie eine Fehlerbehebung ausführen möchten. Für eine Agent Identity müssen Sie stattdessen die Prinzipal-ID angeben.
  • RESOURCE: Die Ressource, für die die Berechtigung gewährt wird.
  • PERMISSION: Die Berechtigung, für die Sie eine Fehlerbehebung durchführen möchten.
  • DESTINATION_IP: Optional. Die IP-Adresse des Anforderungsziels, die beim Prüfen bedingter Rollenbindungen verwendet werden soll. Beispiel: 198.1.1.1.
  • DESTINATION_PORT: Optional. Der Zielport der Anfrage, der beim Prüfen bedingter Rollenbindungen verwendet werden soll. Beispiel: `8080`.
  • REQUEST_TIME: Optional. Der Zeitstempel der Anfrage, der beim Prüfen bedingter Rollenbindungen verwendet werden soll. Verwenden Sie einen Zeitstempel im RFC 3339-Format, z. B. 2099-02-01T00:00:00Z.
  • RESOURCE_NAME: Optional. Der Ressourcenname, der beim Prüfen bedingter Rollenbindungen verwendet werden soll. Eine Liste der zulässigen Formate für Ressourcennamen finden Sie unter Format der Ressourcennamen.
  • RESOURCE_SERVICE: Optional. Der Wert des Ressourcendienstes, der beim Prüfen bedingter Rollenbindungen verwendet werden soll. Eine Liste der akzeptierten Dienstnamen finden Sie unter Werte für Ressourcendienste.
  • RESOURCE_TYPE: Optional. Eine Liste der akzeptierten Ressourcentypen finden Sie unter Werte für Ressourcentypen.

HTTP-Methode und URL:

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

JSON-Text anfordern:

{
  "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
      }
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Die Antwort enthält eine Erklärung des Zugriffs des Auftraggebers. Für jede Rollenbindung und jede Ablehnungsregel mit einer Bedingung enthält die Antwort ein conditionExplanation-Feld, das beschreibt, ob die Bedingung basierend auf dem von Ihnen angegebenen Bedingungskontext als „true“ oder „false“ ausgewertet wird.

Das folgende Beispiel zeigt die Auswertung einer Rollenbindung mit einer Bedingung, die den Ressourcentyp und den Ressourcendienst angibt:

...
{
  "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
    }]
  }
}
...

Nächste Schritte