Fehler bei der Autorisierung beheben

Diese Seite ist Teil des Dokuments Auf anstehende Änderungen bei der Autorisierung vorbereiten. Darin werden die Fehler beschrieben, die möglicherweise auftreten, und es wird erklärt, wie Sie sie beheben können.

Eine abgelehnte Aktion hat eine von zwei Ursachen, die sich unterscheiden:

• Das Dienstkonto „Ausführen als“ – entweder können Sie nicht als dieses Konto agieren oder es kann nicht auf die für eine Aufgabe erforderlichen Ressourcen zugreifen. Weitere Informationen finden Sie unter Fehler bei der Ausführung als Dienstkonto.
• Ihre eigene IAM-Rolle: Sie sind nicht berechtigt, die Aktion auszuführen. Weitere Informationen finden Sie unter IAM-Rollenfehler.

Beide Prüfungen werden durchgeführt. Wenn Sie also einen Fehler beheben, wird der andere dadurch nicht automatisch behoben.

Fehler bei „Ausführen als“-Dienstkonto

Einige dieser Prüfungen werden noch eingeführt. Möglicherweise werden dir also noch nicht alle Fehler angezeigt. In den Nachrichten ist PRINCIPAL das Konto, das überprüft wurde. Wenn das Konto nicht benannt werden kann, wird The caller angezeigt.

Situation	Folgendes wird angezeigt:	Was muss ich tun?
Eine Person, Automatisierung oder ein Trigger startet eine Integration, kann aber nicht als ihr Dienstkonto für die Ausführung fungieren.	Der Lauf wird mit dem folgenden Fehler abgelehnt: PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to run this integration. Ein API-Aufruf gibt den Fehler zurück und in Ihren Ausführungsprotokollen wird nichts angezeigt. Bei einem Cloud Pub/Sub-, Eventarc- oder Integration Connectors-Ereignistrigger wird eine fehlgeschlagene Ausführung in Ihren Ausführungsprotokollen aufgezeichnet und das Ereignis wird nicht noch einmal gesendet. Ein Cloud Scheduler-Job meldet einen PERMISSION_DENIED-Fehler.	Rolle „Dienstkontonutzer“ für den Nutzer gewähren, der die Instanz startet. Bei einem Trigger ist das das Dienstkonto des Triggers.
Für eine Integration, die am oder nach dem 15. Oktober 2026 mit einem anderen Trigger als „API“ oder „Private“ erstellt wurde, gibt es kein Dienstkonto für die Ausführung.	Die Veröffentlichung und das Testen schlagen mit dem folgenden Fehler fehl: Set a run-as service account. These triggers run with no caller: TRIGGERS. Required for integrations created on or after October 15, 2026 (UTC).	„Ausführen als“-Dienstkonto festlegen
Bei einem Lauf ohne Nutzeranmeldedaten ist kein Dienstkonto für die Ausführung vorhanden.	Wenn die Integrationsverwaltung für die Region aktiviert ist, schlagen Veröffentlichung und Tests mit dem folgenden Fehler fehl, unabhängig vom Erstellungsdatum der Integration: Your project requires a run-as service account. Set one before publish or test. Die Verwaltung ist die Einstellung Enable governance, die unter Region bearbeiten beschrieben wird. In Regionen ohne Governance lehnt das System diese Läufe ab dem 15. Oktober 2026 nicht mehr ab. Die folgenden Vorgänge werden jedoch in einer zukünftigen Version fehlschlagen: Aufgaben ohne Identität, z. B. Connector-, „REST-Endpunkt aufrufen“- oder Cloud Run Functions-Aufgaben. Asynchrone Ausführungen mit dem folgenden Fehler: Integration NAME needs a run-as service account to run asynchronously via trigger TRIGGER_ID.	„Ausführen als“-Dienstkonto festlegen
Eine Aufgabe für die Anrufintegration kann ihre untergeordnete Integration nicht starten.	Die Aufgabe „Anrufintegration“ der Anrufintegration schlägt aus einem der folgenden Gründe fehl: Die Unterintegration wird asynchron aufgerufen und hat kein Dienstkonto für die Ausführung als Dienstkonto, auch wenn die aufrufende Integration eines hat: Integration NAME needs a run-as service account to run asynchronously via trigger TRIGGER_ID. Derjenige, der die Anrufintegration gestartet hat, oder das Run-as-Dienstkonto der Anrufintegration kann nicht als Run-as-Dienstkonto der untergeordneten Integration fungieren: PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to run this integration.	Legen Sie ein Dienstkonto für die Ausführung als Nutzer für die Subintegration fest oder rufen Sie sie synchron auf. Weisen Sie dann die Rolle „Dienstkontonutzer“ zu.
Jemand veröffentlicht oder testet eine Integration, für die ein Authentifizierungsprofil verwendet wird, als dessen Dienstkonto er nicht agieren kann, oder ein Lauf erreicht eine Aufgabe, für die es verwendet wird.	Die Veröffentlichung oder das Testen schlägt fehl oder die Aufgabe schlägt mit dem folgenden Fehler fehl: PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to use auth config "AUTH_PROFILE_NAME". Ob der Rest des Laufs fortgesetzt wird, hängt davon ab, wie die Aufgabe Fehler behandelt.	Rolle „Service Account User“ für das im Profil angegebene Konto gewähren
Jemand erstellt oder bearbeitet ein Authentifizierungsprofil vom Typ Dienstkonto oder OIDC-Token ohne die Berechtigung, als Dienstkonto zu agieren.	Das Speichern des Profils schlägt mit dem folgenden Fehler fehl: PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to save this auth config.	Rolle „Service Account User“ für das im Profil angegebene Konto dem Nutzer zuweisen, der es verwaltet
Ein Genehmiger kann nicht als „Ausführen als“-Dienstkonto fungieren	Das Genehmigen oder Fortsetzen des Laufs schlägt mit dem folgenden Fehler fehl: PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to resume this execution. Der Lauf bleibt pausiert, bis er abläuft. Es kann also so aussehen, als ob Genehmigungen nicht mehr funktionieren.	Rolle „Service Account User“ allen Nutzern zuweisen, die Genehmigungen erteilen können
Jemand veröffentlicht oder testet eine Integration ohne die Berechtigung, als zugehöriges Dienstkonto zu fungieren.	PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to publish or test this integration. Bereits veröffentlichte Inhalte werden weiterhin ausgeführt. Wenn die Veröffentlichung automatisiert erfolgt, wird dies in Ihrer Bereitstellungspipeline und nicht in der Console angezeigt.	Rolle „Dienstkontonutzer“ für Publisher, Tester und Automatisierung gewähren
Eine Aufgabe wird als die Person ausgeführt, die sie ausgelöst hat, und diese Person kann nicht auf die Ressource zugreifen. In einer neuen Integration und ab dem 15. Oktober 2026 in einem Test einer beliebigen Integration werden die Aufgaben JavaScript, Data Transformer-Script und Datenabgleich so ausgeführt:	Die Ausführung wird normal gestartet, dann schlägt eine Aufgabe fehl, in der eine Ressource genannt wird, obwohl sich an der Integration nichts geändert hat.	Gewähren Sie diesen Personen Zugriff auf die Ressource oder stellen Sie die Integration auf ein Dienstkonto um, das bereits Zugriff hat. Das ist in der Regel die bessere Lösung, da der Zugriff der Integration dann nicht davon abhängt, wer sie ausführt.

Eine vollständige Liste der Fehlercodes für Application Integration finden Sie unter Fehlercodes.

IAM-Rollenfehler

Zusätzlich zum Dienstkonto „Ausführen als“ werden in Application Integration Ihre IAM-Berechtigungen für Nutzer für jede Aktion überprüft. Wenn beim Interagieren mit einer Integration der Fehler PERMISSION_DENIED auftritt oder Ausführungsprotokolle nicht geladen werden, prüfen Sie, ob Sie eine Rolle mit den erforderlichen Berechtigungen haben:

So gehts	Sie benötigen eine dieser Rollen
Integrationen ansehen und öffnen	roles/integrations.integrationViewer
Ausführungslogs und ‑details ansehen	roles/integrations.integrationViewer oder roles/integrations.integrationInvoker
Integration ausführen	roles/integrations.integrationInvoker oder roles/integrations.integrationEditor
Integrationen erstellen und bearbeiten	roles/integrations.integrationEditor
Integration veröffentlichen	roles/integrations.integrationDeployer oder roles/integrations.integrationEditor
Angehaltenen Lauf genehmigen oder fortsetzen	roles/integrations.suspensionResolver oder roles/integrations.integrationAdmin
Vollständiger Zugriff auf alle Integrationen	roles/integrations.integrationAdmin

Hinweis:Zum Genehmigen oder Fortsetzen eines angehaltenen Laufs ist die Berechtigung integrations.suspensions.resolve erforderlich, die in der Rolle roles/integrations.integrationEditor nicht enthalten ist. Genehmiger benötigen die Rolle roles/integrations.suspensionResolver sowie die Rolle „Dienstkontonutzer“ (roles/iam.serviceAccountUser) für das Dienstkonto, das als Ausführungskonto verwendet wird.

Hinweis:Mit keiner dieser Rollen können Sie ändern, wer Zugriff hat. Zum Zuweisen der auf dieser Seite beschriebenen Rollen und Berechtigungen ist eine separate Rolle erforderlich:

• roles/iam.serviceAccountAdmin, um die Rolle „Dienstkontonutzer“ für ein Dienstkonto zuzuweisen.
• roles/resourcemanager.projectIamAdmin, um Application Integration-Rollen auf Projektebene zuzuweisen.

Project Owner haben beide. Wenn Sie selbst keine Zuwendung leisten können, bitten Sie einen Administrator, dies zu tun.

Führen Sie zum Zuweisen einer Rolle den folgenden Befehl aus:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='ROLE'

Hier finden Sie weitere Informationen:

• Vordefinierte IAM-Rollen für die vollständige Liste der Rollen und der Berechtigungen, die in den einzelnen Rollen enthalten sind.
• Zugriffssteuerung: Hier erfahren Sie, wie Application Integration IAM verwendet.

Achtung:Wenn Ihre Organisation Rollen mithilfe von IAM-Bedingungen auf einzelne Integrationen beschränkt, muss die Bedingung mit der jeweiligen Integration übereinstimmen, auf die Sie zugreifen. Eine Rollenbindung, die Zugriff auf eine Integration gewährt, kann den Zugriff auf eine andere verweigern. Wenn Sie trotz der richtigen Rolle Berechtigungsfehler erhalten, prüfen Sie die Bedingungen, die an Ihre Rollenbindung angehängt sind.

Der Fehler wurde durch eine Kulanzleistung nicht behoben

• Die Förderung wurde dem falschen Projekt zugewiesen. Sie muss im Projekt mit dem Dienstkonto erfolgen, das nicht unbedingt das Projekt mit der Integration ist.
• Die Änderung ist noch nicht in Kraft getreten. Warten Sie einige Minuten. Autorisierungsentscheidungen werden zusätzlich zur normalen IAM-Verzögerung kurz im Cache gespeichert.
• Es ist ein zweites Dienstkonto beteiligt. Ihr Dienstkonto „Ausführen als“, das Dienstkonto jedes Authentifizierungsprofils und das Dienstkonto „Ausführen als“ jeder untergeordneten Integration sind separat und benötigen jeweils eine eigene Erteilung.
• Die Zuwendung wurde an das falsche Hauptkonto gesendet. Bei einem Cloud Scheduler-, Cloud Pub/Sub-, Eventarc- oder Integration Connectors-Ereignistrigger ist das Prinzipal, das die Gewährung benötigt, das Dienstkonto des Triggers und nicht Sie. Weitere Informationen finden Sie unter Wer benötigt die Rolle „Dienstkontonutzer“?.
• Die Blockierung betrifft Ihre eigene Rolle, nicht das Dienstkonto. Bei „Service Account User“ geht es darum, ob Sie als das Run-as-Dienstkonto agieren dürfen. Eine separate IAM-Rolle regelt, ob Sie die Aktion ausführen dürfen. Weitere Informationen finden Sie unter IAM-Rollenfehler.