Anwendungsfälle für die Fehlerbehebung bei Zugriffsproblemen in Google Cloud

Last reviewed 2022-09-29 UTC

In diesem Dokument wird beschrieben, wie Sie mit Google Cloud-Tools Anwendungsfälle im Zusammenhang mit Problemen beim Zugriff auf Google Cloud-Ressourcen beheben. In diesem Dokument wird nicht beschrieben, wie Sie Fehler beim Endnutzerzugriff auf Ihre Anwendungen beheben. In diesem Dokument wird davon ausgegangen, dass Sie mit der Fehlerbehebung bei Richtlinien- und Zugriffsproblemen in Google Cloud vertraut sind. Das Dokument zum Beheben von Richtlinien- und Zugriffsproblemen beschreibt die Google Cloud-Dienste, die Zugriffsrichtlinien erzwingen können, sowie die von Google Cloud bereitgestellten Tools zur Fehlerbehebung.

Ansatz zur Fehlerbehebung

Der erste Schritt zur Behebung eines Zugriffsproblems besteht darin, den Ansatz zur Fehlerbehebung zu bestimmen. Das folgende Diagramm zeigt ein Flussdiagramm eines Ansatzes zur Behebung von Zugriffsproblemen. In diesem Flussdiagramm wird davon ausgegangen, dass Sie die entsprechenden Berechtigungen zum Ausführen der Schritte zur Fehlerbehebung haben oder mit einer Person zusammenarbeiten können, die die erforderlichen Berechtigungen hat.

Ein Flussdiagramm für einen Ansatz zur Behebung von Zugriffsproblemen.

Das obige Diagramm veranschaulicht die folgenden Schritte:

Überprüfen Sie den Nutzerzugriff in der Google Cloud Console und in Cloud Shell. Wenn der gesamte Zugriff verweigert wird, prüfen Sie die Audit-Logs auf Einträge mit Schweregrad des Fehlers.
1. Wenn Fehler-Schweregrad-Einträge enthalten sind, überprüfen Sie die erforderlichen Berechtigungen.
  1. Wenn Sie Berechtigungen gewähren können, um Zugriffsprobleme zu beheben, lösen Sie das Problem.
  2. Wenn Sie die Zugriffsprobleme nicht beheben können, wenden Sie sich an den Cloud Customer Care.
2. Wenn keine Fehler-Schweregrad-Einträge vorliegen, wenden Sie sich an den Kundenservice.
Falls keine Zugriffsprobleme vorhanden sind, suchen Sie nach Netzwerkproblemen. Wenn Sie Netzwerkprobleme erkennen, beheben Sie sie.
Wenn keine Netzwerkprobleme vorhanden sind, prüfen Sie die Kontingentzuweisung. Wenn bei der Kontingentzuweisung Probleme vorliegen, folgen Sie der Anleitung zum Erhöhen von Kontingenten und lösen Sie dann das Problem.
Wenn keine Probleme mit der Kontingentzuweisung vorliegen, prüfen Sie die Audit-Logs auf Fehler-Schweregrad-Einträge.
1. Wenn Fehler-Schweregrad-Einträge enthalten sind, überprüfen Sie die erforderlichen Berechtigungen.
  1. Wenn Sie Berechtigungen gewähren können, um Zugriffsprobleme zu beheben, lösen Sie das Problem.
  2. Wenn sich die Zugriffsprobleme nicht lösen lassen, wenden Sie sich an den Customer Care.
2. Wenn keine Fehler-Schweregrad-Einträge vorliegen, wenden Sie sich an den Kundenservice.

Die folgenden Abschnitte enthalten Details zum Ausführen der einzelnen Schritte zur Fehlerbehebung.

Bestätige den Nutzerzugriff

Prüfen Sie, ob der Nutzerzugriff sowohl in der Google Cloud Console als auch in der Google Cloud CLI verweigert wird:

Melden Sie sich in der Google Cloud Console als der betroffene Nutzer an.
Versuchen Sie, auf die Ressource zuzugreifen: Wenn der Nutzer beispielsweise gemeldet hat, dass er keine VM starten kann, versuchen Sie, eine VM zu starten.
Öffnen Sie Cloud Shell in der Google Cloud Console und führen Sie in einer Sitzung, in der der Nutzer angemeldet ist, den folgenden gcloud-Befehlszeilenbefehl aus. Mit diesem Befehl können Sie prüfen, ob der Nutzer in der richtigen Identität angemeldet ist und ob er mit dem gcloud CLI auf die Ressource zugreifen kann.
```
gcloud auth list
```
Die Ausgabe gibt das Konto zurück, in dem der Nutzer angemeldet ist.
Prüfen Sie, ob der vorherige Befehl die richtige Identität zurückgibt.
- Wenn der vorherige Befehl die falsche Identität zurückgibt, bitten Sie den Nutzer, sich mit der richtigen Identität anzumelden. Prüfen Sie dann, ob der Zugriff bei Verwendung der richtigen Identität immer noch verweigert wird.
- Wenn der vorherige Befehl die richtige Identität zurückgibt und Sie die Meldung permission denied erhalten, führen Sie den Befehl des gcloud CLI für die Aktion aus, die der Nutzer ausführen möchte. Fügen Sie die Flags --log-http und --verbosity=debug hinzu, um weitere Informationen zur Zugriffsverweigerung zu erhalten.
Wenn Sie ein Problem im Zusammenhang mit Berechtigungen feststellen, fahren Sie mit Erforderliche Berechtigungen prüfen fort.

Auf Netzwerkprobleme prüfen

Nutzen Sie die Anleitung zur Fehlerbehebung bei VPC Service Controls, um auf Netzwerkprobleme zu prüfen. Wenn eine Fehlermeldung zur Verweigerung von VPC Service Controls angezeigt wird, beheben Sie das Problem.
Prüfen Sie die Netzwerkpfade von der Quelle zum Ziel mithilfe von Konnektivitätstests. Informationen zum Testen der Konnektivität zwischen zwei VM-Instanzen im selben Netzwerk oder Peering-Netzwerken finden Sie unter In VPC-Netzwerken testen.
Prüfen Sie die Firewallkonfiguration mithilfe von Firewall Insights, um alle verdeckte Firewallregeln und alle Ablehnungs-Regeln anzuzeigen, die sich vielleicht auf Zugriffspfade auswirken.

Kontingentzuweisung prüfen

Wenn Sie keine netzwerkbezogenen Probleme finden, prüfen Sie die Kontingentzuweisung. Wenn ein kontingentbezogenes Problem vorzuliegen scheint, folgen Sie dem definierten Prozess, um das Kontingent gegebenenfalls zu erhöhen.

Audit-Logs prüfen

Prüfen Sie die Audit-Log-Dateien mit dem Log-Explorer. Der Log-Explorer bietet eine Zusammenfassung des Schweregrads eines Logeintrags. Der Schweregrad eines Fehlerlogs wird aufgezeichnet, wenn ein API-Aufruf fehlschlägt. Beispiel: Ein Fehler wird aufgezeichnet, wenn ein Nutzer versucht, einen Cloud Storage-Bucket zu erstellen, aber nicht berechtigt ist, storage.buckets.create aufzurufen.

Die Zusammenfassung eines Logeintrags enthält folgende Details:
- Name der Zielressource
- Hauptkonto (der versucht, auf die Ressource zuzugreifen)
- API-Aufruf, den das Hauptkonto versucht hat, auszuführen

Erforderliche Berechtigungen prüfen

Verwenden Sie die Policy Troubleshooter, um festzustellen, warum das Hauptkonto nicht die erforderlichen Berechtigungen hat:

Wenn Sie anhand der Prüfungen feststellen, dass der Zugriff nicht gewährt wird, prüfen Sie, welche Rollen laut Policy Troubleshooter die Berechtigung enthalten.
Verwenden Sie das Policy Analyzer, um zu sehen, welche anderen Hauptkonten Zugriff auf die Ressource haben, auf die das Hauptkonto nicht zugreifen darf.
Fügen Sie die Identität des Hauptkontos der Google-Gruppe hinzu, die eine Bindung an die entsprechende Rolle hat.

Kundenservice kontaktieren

Wenn Sie die vorigen Abschnitte zur Fehlerbehebung ausgeführt haben und das Problem nicht beheben können, wenden Sie sich an den Kundensupport. Geben Sie so viele Informationen wie möglich an, wie im Fehlerbehebungsanleitungsabschnitt unter An Kundenbetreuung eskalieren beschrieben.

Anwendungsfallbeispiele zur Fehlerbehebung

Dieser Abschnitt enthält ausführliche Schritt-für-Schritt-Anleitungen zur Fehlerbehebung in bestimmten Anwendungsfällen anhand der vorherigen Schritte zur Fehlerbehebung. Für alle Anwendungsfälle benötigen Sie die entsprechenden Berechtigungen zur Verwendung der Tools zur Fehlerbehebung, die unter Richtlinien- und Zugriffsprobleme in Google Cloud beheben beschrieben werden.

In den folgenden Anwendungsfällen wird davon ausgegangen, dass Sie Google Groups zum Verwalten des Nutzerzugriffs verwenden. Wenn Sie Google Groups zum Gewähren von Berechtigungen verwenden, können Sie den Zugriff in großem Umfang verwalten. Jedes Mitglied einer Google-Gruppe erbt die dieser Gruppe zugewiesenen IAM-Rollen. Auf diese Weise können Sie über die Mitgliedschaft in einer Gruppe die Rollen der Nutzer verwalten und müssen nicht jedem einzelnen Nutzer IAM-Rollen zuweisen.

Rollendelegator übernimmt Fehlerbehebung für Entwicklerzugriff auf Compute-Administrator-Rolle

Als Delegator von Rollen muss ich verstehen, warum ich einem Entwickler eine bestimmte Rolle nicht zuweisen kann. Ich erteile neuen Entwicklern regelmäßig Compute-Administrator-Rollen, wenn sie meinem Team beitreten. Heute habe ich versucht, die Rolle "Compute-Instanzadministrator" zuzuweisen, und wurde abgelehnt.

Nachdem Sie anhand des Flussdiagramm den Zugriff der Nutzer überprüft und Audit-Logs überprüft haben, können Sie bestätigen, dass es sich um ein Berechtigungsproblem handelt.

Zum Zuweisen von Rollen benötigen Sie die Berechtigung resourcemanager.projects.setIamPolicy. Diese Berechtigung kann als Teil der folgenden Rollen gewährt werden:

Rolle "Administrator der Organisation" (roles/resourcemanager.organizationAdmin)
IAM-Rolle "Ordneradministrator" (roles/resourcemanager.folderIamAdmin)
IAM-Rolle "Projekt-Administrator" (roles/resourcemanager.projectIamAdmin)

Mit der Richtlinien-Fehlerbehebung können Sie feststellen, ob dem Rollendelegator die Berechtigung resourcemanager.projects.setIamPolicy zugewiesen ist. Wenn die Berechtigung nicht mehr zugewiesen ist, prüfen Sie Folgendes:

Prüfen Sie, ob eine IAM-Empfehlung angewendet wurde, die möglicherweise die Richtlinie widerrufen hat.
Wenn Sie wissen, wann Sie Rollen zuletzt gewähren konnten, prüfen Sie die Logs zwischen damals und jetzt, um festzustellen, ob setIam-Aufrufe stattgefunden haben, die die angewendeten Richtlinien möglicherweise geändert haben.
Verwenden Sie die Richtlinienanalyse, um zu prüfen, welche Hauptkonten die resourcemanager.projects.setIamPolicy haben. Mit dem Tool "Policy Analyzer" können Sie prüfen, ob der Rollendelegator aus einer Gruppe entfernt wurde.

Cloud-Administrator übernimmt Fehlerbehebung für Entwicklerzugriff auf BigQuery

Ich muss als Cloud-Administrator verstehen, warum einer der Entwickler keine Abfrage mehr für ein BigQuery-Dataset ausführen kann.

Zur Behebung dieses Anwendungsfalls müssen Sie zuerst den Nutzerzugriff prüfen und alle damit verbundenen Probleme beheben. Anschließend prüfen Sie, ob Netzwerkprobleme vorliegen. In diesem Beispiel wird davon ausgegangen, dass Sie festgestellt haben, dass kein Problem mit der Identität oder dem Netzwerk, sondern lediglich ein Berechtigungsproblem vorliegt.

Um das Berechtigungsproblem zu beheben, prüfen Sie zuerst die Berechtigungen der Teammitglieder. Wenn Sie keine Diskrepanzen feststellen, prüfen Sie die Logs, um potenzielle Probleme zu identifizieren. Wenn Sie keine Probleme in den Logs finden, wenden Sie sich an den Customer Care.

Berechtigungen von Teammitgliedern prüfen

Fragen Sie den Entwickler, wann er die Abfrage zuletzt erfolgreich ausführen konnte, um die Berechtigungen der Teammitglieder zu prüfen. Prüfen Sie dann, ob jemand im Entwicklerteam zuvor die Abfrage ausführen konnte und ob diese Person die Abfrage weiterhin erfolgreich ausführen kann. Wenn keines der Teammitglieder die Abfrage ausführen kann, fahren Sie mit dem Abschnitt Logs prüfen fort.

Wenn ein Teammitglied die Abfrage weiterhin ausführen kann, führen Sie die folgenden Schritte aus:

Prüfen Sie die IAM-Berechtigungen, die beiden Entwicklern gewährt werden, und bestimmen Sie, ob sich die Berechtigungen unterscheiden. Achten Sie beim Prüfen der Berechtigungen auf Folgendes:
Wenn die Berechtigungen nicht voneinander abweichen, fahren Sie mit dem nächsten Abschnitt Logs prüfen fort. Wenn die Berechtigungen voneinander abweichen, führen Sie die folgenden Schritte aus:
1. Prüfen Sie, ob sich beide Teammitglieder in derselben Google-Gruppe befinden.
  - Wenn sie nicht in derselben Google-Gruppe sind, überprüfen Sie, ob sie es sein sollten.
  - Wenn sie sich zuvor in derselben Google-Gruppe befanden, fragen Sie den Gruppenadministrator, warum es geändert wurden.
Nachdem Sie das Berechtigungsproblem behoben haben, prüfen Sie, ob der Entwickler die Abfrage ausführen kann.
- Wenn der Entwickler die Abfrage ausführen kann, beheben Sie das Problem.
- Wenn der Entwickler die Abfrage nicht ausführen kann, fahren Sie mit dem nächsten Abschnitt Logs prüfen fort.

Logs prüfen

Wenn keine Teammitglieder die Abfrage ausführen können oder das Problem durch die Behebung von Berechtigungsproblemen nicht behoben wurde, prüfen Sie die Logs, um festzustellen, was sich seit der letzten erfolgreichen Durchführung der Abfrage durch den Entwickler möglicherweise geändert hat.

Festlegen, wo die Logs für die zuletzt erfolgreich abgeschlossene Aufgabe angezeigt werden sollen. In diesem Beispiel werden die Logs nach BigQuery exportiert.
Führen Sie Abfragen der exportierten Logs in BigQuery aus:
1. Führen Sie eine Abfrage aus, die das letzte erfolgreiche Datum enthält, wo der Entwickler Zugriff hatte, um sehen zu können, wie Erfolg aussieht.
2. Führen Sie dieselbe Abfrage zu der Zeit aus, als die Anfrage fehlgeschlagen ist.
Wenn in den Logs etwas erkennbar ist, beheben Sie das Problem mithilfe der Policy Troubleshooter und des Policy Analyzer wie im Abschnitt Überprüfen Sie die erforderlichen Berechtigungen beschrieben.
Wenn Sie das Problem dennoch nicht beheben können, wenden Sie sich an den Customer Care.

Entwickler benötigt Berechtigungen für GKE

Als Entwickler muss ich verstehen, warum ich einen Pod nicht starten, löschen oder aktualisieren oder ein Deployment im Google Kubernetes Engine-Cluster (GKE) erstellen kann, auf den ich Zugriff habe. Ich bin mir nicht sicher, welches Hauptkonto ich bin, wenn ich den Aufruf über das kubectl-Befehlszeilentool mache, und welche Berechtigungen ich habe.

Die IAM-Rolle, mit der Entwickler einen Pod starten, löschen oder aktualisieren oder ein Deployment im GKE-Cluster erstellen können, ist die Rolle "Google Kubernetes Engine-Entwickler" (roles/container.developer). Diese Rolle sollte in dem Projekt gewährt werden, in dem sich der GKE-Cluster befindet.

Zur Behebung dieses Anwendungsfalls müssen Sie zuerst den Nutzerzugriff prüfen und alle damit verbundenen Probleme beheben. Nachdem Sie die Identität validiert haben, prüfen Sie, ob das kubectl-Tool so konfiguriert ist, dass es auf den richtigen Cluster verweist. Informationen zum Prüfen, ob die vom kubectl-Tool verwendete Identität korrekt ist und dass das kubectl-Tool auf den richtigen Cluster verweist, finden Sie unter Clusterzugriff konfigurieren für kubectl. In diesem Beispiel wird davon ausgegangen, dass Sie nicht festgestellt haben, dass ein Netzwerk- oder ein Kontingentproblem, sondern ein Berechtigungsproblem vorliegt.

Zur Behebung des Berechtigungsproblems prüfen Sie die Audit-Logs, um zu sehen, was sich zwischen der letzten erfolgreichen Aktion des Entwicklers und dem Zeitpunkt der ersten Meldung des Problems geändert hat.

Wenn der Entwickler bereits Zugriff hatte, prüfen Sie, ob ein Teammitglied, das auch berechtigt ist, dieselben Aktionen auszuführen. Wenn das Teammitglied Zugriff hat, verwenden Sie das Policy Analyzer, um zu bestimmen, welchen Zugriff das Teammitglied hat. Wenn Sie sich an Best Practices halten, sollten beide Entwickler die gleiche Gruppenmitgliedschaft und dieselben Berechtigungen haben.
1. Wenn ihre Berechtigungen identisch sind und kein Entwickler die Aktionen für die Ressource ausführen kann, prüfen Sie, ob IAM-Empfehlungen angewendet wurden, die sich auf den Zugriff auswirken könnten.
2. Wenn deren Berechtigungen unterschiedlich sind, finden Sie heraus den Grund dafür:
  1. Prüfen Sie die Audit-Logs, um zu bestimmen, wann der Entwickler die Aufgabe das letzte Mal erfolgreich ausgeführt hat. Vergleichen Sie die Logs mit dem letzten fehlgeschlagenen Versuch der Person, die Aufgabe auszuführen.
  2. Prüfen Sie die IAM-Empfehlungen und wenden Sie sie an.
Wenn es kein anderes Teammitglied gibt, mit dem Sie validieren können, verwenden Sie die Policy Troubleshooter und den Policy Analyzer wie in Prüfen Sie die erforderlichen Berechtigungen beschrieben. Weitere Informationen finden Sie in den folgenden Ressourcen:
Wenn Sie das Problem dennoch nicht beheben können, wenden Sie sich an den Customer Care.

Sicherheitsadministrator übernimmt Fehlerbehebung für Entwicklerzugriff

Als Sicherheitsadministrator muss ich verstehen, warum ein Entwickler eine Aktion nicht ausführen konnte. Welche Rolle und welcher Standort sollten am besten der Rolle zugewiesen werden, damit die Rolle nicht mehr Zugriff bietet, als der Nutzer benötigt?

In diesem Szenario muss der Entwickler in der Lage sein:

Objekte in einen Cloud Storage-Bucket hochzuladen Der Entwickler sollte keine Möglichkeit haben, vorhandene Objekte im Bucket aufzurufen, zu löschen oder zu überschreiben.
Starten Sie Instanzen in deren Entwicklungsprojekt.

Mithilfe der Richtlinien-Fehlerbehebung und auf der Referenzseite Informationen zu IAM-Rollen können Sie ermitteln, welche Berechtigungen der Entwickler zum Ausführen der Aufgabe benötigt. In diesem Beispiel müssen Sie Ihrem Entwickler eine Rolle mit den folgenden Berechtigungen zuweisen:

Damit der Entwickler Instanzen beenden und starten kann: compute.instances.start und compute.instances.stop
So erlauben Sie dem Entwickler, Objekte in Cloud Storage-Buckets hochzuladen: storage.objects.create

Die folgenden Rollen enthalten die vorhergehenden Berechtigungen und halten sich an das Prinzip der geringsten Berechtigung:

Auf Bucket-Ebene für den Bucket, in den der Entwickler Objekte hochladen kann, weisen Sie die Rolle "Storage-Objekt-Ersteller" (roles/storage.objectCreator) zu.
Erteilen Sie auf Projektebene des zugewiesenen Projekts des Entwicklers oder auf der Instanz, die der Entwickler neu starten muss, die Rolle "Compute-Instanzadministrator" (roles/compute.instanceAdmin).

Für die Verwaltung von Instanzen sind in der Regel auch Aktionen wie das Hinzufügen von Laufwerken erforderlich. In diesem Fall kann die Rolle roles/compute.instanceAdmin geeignet sein, um die erforderlichen Berechtigungen zu gewähren und gleichzeitig das Prinzip der geringsten Berechtigung einzuhalten.

Cloud-Administrator übernimmt Fehlerbehebung, wenn eine Anwendung keine Daten in Cloud Storage schreiben kann

Als Cloud-Administrator muss ich verstehen, warum eine in GKE ausgeführte Anwendung keine Daten mehr in Cloud Storage schreiben kann.

In diesem Szenario muss eine in GKE ausgeführte Anwendung so konfiguriert werden:

Für einen angegebenen Bucket kann die Anwendung Objekte hinzufügen, aktualisieren und löschen.
Die Anwendung darf keinen Zugriff auf andere Buckets in der Organisation haben.

Beim folgenden Ansatz zur Fehlerbehebung wird davon ausgegangen, dass Sie Workload Identity verwenden, was wir empfehlen. Mit Workload Identity können Sie ein Kubernetes-Dienstkonto konfigurieren, das es als Google-Dienstkonto fungiert. Pods, die als das Kubernetes-Dienstkonto ausgeführt werden, werden automatisch als Google-Dienstkonto authentifiziert, wenn sie auf Google Cloud APIs zugreifen.

In diesem Beispiel prüfen Sie, ob Sie dem Google-Dienstkonto, das Sie für Workload Identity für Ihren Cluster verwenden, die entsprechenden Berechtigungen erteilt haben. Informationen zu den Berechtigungen, die zum Ausführen der Aufgaben Ihrer Anwendung erforderlich sind, finden Sie unter Richtlinien-Fehlerbehebung und auf der Referenzseite Informationen zu IAM-Rollen. So konfigurieren und prüfen Sie Berechtigungen:

Weisen Sie dem Google-Dienstkonto, das Sie für Workload Identity verwenden, die folgenden Berechtigungen zu:
1. Gewähren Sie dem Bucket, für den die Anwendung vollständige Kontrolle der Objekte hat, darunter Auflisten, Erstellen, Aufrufen und Löschen von Objekten, die Rolle Storage-Objekt-Administrator (roles/storage.objectAdmin).
2. Um das Kubernetes-Dienstkonto so zu konfigurieren, dass es die Identität des Google-Dienstkontos annimmt, legen Sie eine IAM-Richtlinienbindung fest:
```
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KSA_NAME]" \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
```
  Ersetzen Sie die folgenden Werte:
  - PROJECT_ID: Ihre Projekt-ID
  - KSA_NAME: das Kubernetes-Dienstkonto, das die Anfrage stellt
  - KUBERNETES_NAMESPACE ist der Kubernetes-Namespace, in dem das Kubernetes-Dienstkonto definiert ist.
  - GSA_NAME: das Google-Dienstkonto
Legen Sie die Berechtigung iam.serviceAccounts.setIamPolicy für das Projekt fest:
- Fügen Sie dem Kubernetes-Dienstkonto die folgende Annotation hinzu:
```
iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID
```
Prüfen Sie, ob das Google-Dienstkonto die richtigen Berechtigungen hat und Workload Identity richtig konfiguriert ist:
1. Rufen Sie in dem Bucket, für den die Anwendung vollständige Kontrolle der Objekte hat, die IAM-Richtlinie für den Bucket auf und prüfen Sie, ob das Google-Dienstkonto die roles/storage.objectAdmin Rolle hat.
2. Wenn die Berechtigungen nicht korrekt sind, ändern Sie die Richtlinie, um dem Google-Dienstkonto die erforderliche Berechtigung zu erteilen.
Prüfen Sie, ob Workload Identity ordnungsgemäß konfiguriert ist. Prüfen Sie dazu, ob eine Bindung an das Kubernetes-Dienstkonto vorhanden ist:
```
gcloud iam service-accounts get-iam-policy \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
```
Die Ausgabe sieht so aus:
```
- members:
  - serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KSA_NAME]
  role: roles/iam.workloadIdentityUser
```
Wenn die Bindung falsch ist, wiederholen Sie die vorherigen Schritte, um dem Dienstkonto Berechtigungen zuzuweisen.

Nächste Schritte

Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center