Résoudre les erreurs d'autorisation

Cette page fait partie de la section Se préparer aux prochains changements d'autorisation. Elle explique les erreurs que vous êtes susceptible de rencontrer et comment les corriger.

Une action refusée peut avoir deux causes. Il est important de les distinguer :

• Le compte de service "Exécuter en tant que" : soit vous ne pouvez pas agir en son nom, soit il ne peut pas accéder à ce dont une tâche a besoin. Consultez Erreurs liées au compte de service "Exécuter en tant que".
• Votre propre rôle IAM : vous n'êtes pas autorisé à effectuer l'action. Consultez Erreurs liées aux rôles IAM.

Les deux vérifications s'appliquent. Par conséquent, corriger l'une ne corrige pas l'autre.

Erreurs liées au compte de service "Exécuter en tant que"

Certaines de ces vérifications sont encore en cours de déploiement. Il est donc possible que vous ne voyiez pas encore toutes les erreurs. Dans les messages, PRINCIPAL correspond au compte qui a été vérifié. The caller s'affiche lorsque le compte ne peut pas être nommé.

Situation	Résultat	Que devez-vous faire ?
Une personne, une automatisation ou un déclencheur démarre une intégration, mais ne peut pas agir en tant que compte de service "Exécuter en tant que".	L'exécution est rejetée avec l'erreur suivante : PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to run this integration. Un appel d'API renvoie l'erreur, et rien n'apparaît dans vos journaux d'exécution. Un déclencheur d'événement Cloud Pub/Sub, Eventarc ou Integration Connectors enregistre une exécution ayant échoué dans vos journaux d'exécution, et l'événement n'est pas envoyé à nouveau. Un job Cloud Scheduler renvoie une erreur PERMISSION_DENIED.	Attribuez le rôle Utilisateur du compte de service à la personne qui lance le processus. Pour un déclencheur, il s'agit du compte de service du déclencheur.
Une intégration créée le 15 octobre 2026 ou après, avec un déclencheur autre que l'API ou "Privé", ne dispose pas de compte de service "Exécuter en tant que".	La publication et le test échouent avec l'erreur suivante : Set a run-as service account. These triggers run with no caller: TRIGGERS. Required for integrations created on or after October 15, 2026 (UTC).	Définir un compte de service "Exécuter en tant que"
Une exécution sans identifiants utilisateur n'a pas de compte de service "Exécuter en tant que".	Si la gouvernance de l'intégration est activée pour la région, la publication et le test échouent avec l'erreur suivante, quelle que soit la date de création de l'intégration : Your project requires a run-as service account. Set one before publish or test.. La gouvernance correspond au paramètre Activer la gouvernance décrit dans Modifier la région. Pour les régions sans gouvernance, le système n'acceptera plus ces exécutions à partir du 15 octobre 2026. Toutefois, les éléments suivants devraient échouer dans une prochaine version : Tâches sans identité, telles que les tâches de connecteurs, d'appel de point de terminaison REST ou de fonctions Cloud Run. Exécutions asynchrones, avec l'erreur suivante : Integration NAME needs a run-as service account to run asynchronously via trigger TRIGGER_ID.	Définir un compte de service "Exécuter en tant que"
Une tâche d'appel d'intégration ne peut pas démarrer sa sous-intégration	La tâche d'appel d'intégration de l'intégration appelante échoue pour l'une des raisons suivantes : La sous-intégration est appelée de manière asynchrone et ne possède pas de compte de service "Exécuter en tant que", même si l'intégration appelante en possède un : Integration NAME needs a run-as service account to run asynchronously via trigger TRIGGER_ID. La personne qui a lancé l'intégration d'appel ou le compte de service exécuté en tant que de l'intégration d'appel ne peut pas agir en tant que compte de service exécuté en tant que de la sous-intégration : PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to run this integration.	Définissez un compte de service "Exécuter en tant que" sur la sous-intégration ou appelez-la de manière synchrone. Ensuite, accordez-lui le rôle Utilisateur du compte de service.
Un utilisateur publie ou teste une intégration qui utilise un profil d'authentification dont il ne peut pas emprunter l'identité du compte de service, ou une exécution atteint une tâche qui l'utilise.	La publication ou le test échouent, ou la tâche échoue, avec l'erreur suivante : PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to use auth config "AUTH_PROFILE_NAME". La poursuite du reste de l'exécution dépend de la façon dont la tâche gère les erreurs.	Attribuer le rôle Utilisateur du compte de service au compte indiqué dans le profil
Une personne crée ou modifie un profil d'authentification Compte de service ou Jeton OIDC sans autorisation d'agir en tant que compte de service.	L'enregistrement du profil échoue avec l'erreur suivante : PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to save this auth config.	Attribuez le rôle Utilisateur du compte de service sur le compte nommé dans le profil à la personne qui le gère.
Un approbateur ne peut pas agir en tant que compte de service "Exécuter en tant que"	L'approbation ou la reprise de l'exécution échouent et l'erreur suivante s'affiche : PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to resume this execution. L'exécution reste en pause jusqu'à son expiration. Il peut donc sembler que les approbations ne fonctionnent plus.	Attribuez le rôle Utilisateur du compte de service à toutes les personnes susceptibles d'approuver la demande.
Une personne publie ou teste une intégration sans autorisation d'agir en tant que compte de service d'exécution.	PRINCIPAL needs roles/iam.serviceAccountUser on SERVICE_ACCOUNT (or its project) to publish or test this integration. Tout ce qui a déjà été publié continue de fonctionner. Si l'automatisation publie pour vous, cela apparaît dans votre pipeline de déploiement plutôt que dans la console.	Accorder le rôle "Utilisateur du compte de service" aux éditeurs, aux testeurs et à l'automatisation
Une tâche s'exécute en tant que personne qui l'a déclenchée, et cette personne ne peut pas accéder à la ressource. Dans une nouvelle intégration, et à partir du 15 octobre 2026, dans un test de n'importe quelle intégration, les tâches JavaScript, Data Transformer Script et Mappage de données s'exécutent de cette manière.	L'exécution démarre normalement, puis une tâche échoue en nommant une ressource, même si rien n'a changé dans l'intégration.	Donnez à ces personnes l'accès à la ressource ou déplacez l'intégration vers un compte de service "Exécuter en tant que" qui y a déjà accès. C'est généralement la meilleure solution, car elle empêche l'accès de l'intégration de varier en fonction de la personne qui l'exécute.

Pour obtenir la liste complète des codes d'erreur Application Integration, consultez Codes d'erreur.

Erreurs liées aux rôles IAM

En plus du compte de service "Exécuter en tant que", Application Integration vérifie les autorisations IAM de votre utilisateur pour chaque action. Si vous rencontrez une erreur PERMISSION_DENIED lorsque vous interagissez avec une intégration ou si les journaux d'exécution ne se chargent pas, assurez-vous de disposer d'un rôle qui accorde les autorisations requises :

Pour ce faire :	Vous devez disposer de l'un de ces rôles
Afficher et ouvrir les intégrations	roles/integrations.integrationViewer
Afficher les journaux et les détails d'exécution	roles/integrations.integrationViewer ou roles/integrations.integrationInvoker
Exécuter une intégration	roles/integrations.integrationInvoker ou roles/integrations.integrationEditor
Créer et modifier des intégrations	roles/integrations.integrationEditor
Publier une intégration	roles/integrations.integrationDeployer ou roles/integrations.integrationEditor
Approuver ou reprendre une exécution suspendue	roles/integrations.suspensionResolver ou roles/integrations.integrationAdmin
Accès complet à toutes les intégrations	roles/integrations.integrationAdmin

Remarque : Pour approuver ou réactiver une exécution suspendue, vous devez disposer de l'autorisation integrations.suspensions.resolve, qui n'est pas incluse dans le rôle roles/integrations.integrationEditor. Les approbateurs doivent disposer du rôle roles/integrations.suspensionResolver, ainsi que du rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) sur le compte de service exécuté en tant que.

Remarque : Aucun de ces rôles ne vous permet de modifier les personnes ayant accès à la ressource. Pour accorder les rôles et autorisations décrits sur cette page, vous avez besoin d'un rôle distinct :

• roles/iam.serviceAccountAdmin pour accorder le rôle "Utilisateur du compte de service" sur un compte de service.
• roles/resourcemanager.projectIamAdmin pour attribuer des rôles Application Integration au niveau du projet.

Les propriétaires de projet disposent des deux. Si vous ne pouvez pas accorder vous-même une subvention, demandez à un administrateur de le faire.

Pour attribuer un rôle, exécutez la commande suivante :

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

Pour en savoir plus, consultez les ressources suivantes :

• Rôles IAM prédéfinis : pour obtenir la liste complète des rôles et des autorisations qu'ils contiennent.
• Contrôle des accès : découvrez comment Application Integration utilise IAM.

Attention : Si votre organisation limite les rôles à des intégrations individuelles à l'aide de conditions IAM, la condition doit correspondre à l'intégration spécifique à laquelle vous accédez. Une liaison de rôle qui accorde l'accès à une intégration peut le refuser pour une autre. Si vous rencontrez des erreurs d'autorisation alors que vous disposez du bon rôle, vérifiez les conditions associées à votre liaison de rôle.

Une subvention n'a pas permis de corriger l'erreur

• La subvention a été attribuée au mauvais projet. Elle doit être effectuée dans le projet propriétaire du compte de service, qui n'est pas nécessairement celui propriétaire de l'intégration.
• Elle n'a pas encore pris effet. Patientez quelques minutes. Les décisions d'autorisation sont mises en cache brièvement, en plus du délai de propagation IAM normal.
• Un deuxième compte de service est impliqué. Votre compte de service "Exécuter en tant que", le compte de service de chaque profil d'authentification et le compte de service "Exécuter en tant que" de chaque sous-intégration sont distincts et nécessitent chacun leur propre autorisation.
• L'accès a été accordé au mauvais responsable. Pour un déclencheur d'événement Cloud Scheduler, Cloud Pub/Sub, Eventarc ou Integration Connectors, le principal qui a besoin de l'autorisation est le compte de service du déclencheur, et non vous. Consultez Qui a besoin du rôle "Utilisateur du compte de service" ?.
• Le bloc correspond à votre propre rôle, et non au compte de service. L'utilisateur du compte de service indique si vous pouvez agir en tant que compte de service "Exécuter en tant que". Un rôle IAM distinct détermine si vous êtes autorisé à effectuer l'action. Consultez Erreurs liées aux rôles IAM.