Se préparer aux prochaines modifications des autorisations

Application Integration est en train de modifier la façon dont les intégrations sont autorisées. Ces modifications prendront effet prochainement. La plupart des intégrations continueront de s'exécuter sans aucune modification, tandis que certaines intégrations nécessiteront un changement de configuration pour continuer à s'exécuter. Tout ce qui est décrit sur cette page utilise une configuration que vous contrôlez déjà. Vous pouvez donc effectuer ces modifications dès maintenant.

Prochaines modifications des autorisations

Application Integration est en train de modifier la façon dont il gère les identités pour les exécutions d'intégration. Chaque exécution doit désormais avoir une identité explicite, agissant comme l'un des éléments suivants :

• L'utilisateur qui a déclenché l'exécution. Les systèmes appelés appliquent les autorisations d'accès de cet utilisateur.
• Un compte de service d'exécution. Vous contrôlez, délimitez et auditez ce compte comme n'importe quel autre compte de service de votre projet Google Cloud.

En raison de cette mise à jour :

• Pour exécuter une intégration, vous devez être autorisé à agir en tant que compte de service d'exécution.
• Si aucune des deux identités n'est disponible, l'exécution de l'intégration échoue.

Avant de commencer

Effectuez les tâches suivantes dans l'ordre. Commencez par la première, car les deux autres se terminent par une publication, et la publication elle-même est vérifiée par autorisation.

1. Attribuez le rôle Utilisateur du compte de service à tous les comptes de service d'exécution que vous utilisez déjà, à tous ceux qui exécutent, approuvent, modifient ou publient l'intégration, y compris les comptes de service utilisés par votre automatisation.
2. Définissez un compte de service d'exécution sur les intégrations qui s'exécutent sans personne et qui n'en ont pas.
3. Attribuez le rôle Utilisateur du compte de service au compte de service nommé dans chaque profil d'authentification de type Compte de service ou Jeton OIDC. Il s'agit généralement de comptes différents de votre compte de service d'exécution.

Avertissement : Effectuez la tâche 1 avant les tâches 2 et 3. Définir ou modifier un compte de service d'exécution signifie publier l'intégration, et la publication nécessite la même autorisation. Si vous définissez le compte de service en premier, la publication qui aurait enregistré votre correctif peut être refusée.

Intégrations nécessitant un compte de service d'exécution

Déterminer si une intégration en a besoin

Vous n'avez besoin d'un compte de service d'exécution que lorsque les identifiants de personne ne sont pas disponibles pour l'ensemble de l'exécution. Cela se produit dans deux situations, et seulement deux :

Mode d'exécution de l'intégration	Les identifiants d'une personne sont-ils disponibles ?	Nécessite-t-il un compte de service d'exécution ?
De manière synchrone : une personne la démarre et attend le résultat	Oui, pour l'ensemble de l'exécution	Non
De manière asynchrone : elle est mise en file d'attente et se termine ultérieurement	Uniquement au moment où elle est déclenchée	Oui
Sans surveillance : une programmation ou un événement la démarre	Non, il n'y a jamais de personne	Oui

Remarque : Les exécutions asynchrones sont comptabilisées même si une personne les a déclenchées : le travail mis en file d'attente ne contient pas les identifiants de cette personne. Par conséquent, au moment de l'exécution, il n'y a plus personne pour l'autoriser. Une intégration qui ne s'exécute que de manière synchrone possède déjà une identité et n'a pas besoin d'être modifiée.

Identifier les intégrations concernées

Tout d'abord, s'exécute-t-elle parfois sans personne ? C'est le cas si l'une des conditions suivantes est remplie :

• Elle comporte un déclencheur d'événement Cloud Scheduler, Cloud Pub/Sub, Salesforce, ou Integration Connectors event trigger.
• Un élément la programme via l'API avec scheduleIntegrations.
• Une autre intégration l'appelle en tant que sous-intégration asynchrone à l'aide de la tâche "Appeler l'intégration".
• Elle utilise la tâche "Suspendre" ou "Approbation", où une exécution peut rester en attente, puis expirer d'elle-même.

Ensuite, son compte de service d'exécution est-il vide ? Pour répertorier chaque version publiée dans une région avec son compte de service d'exécution, exécutez la commande suivante :

curl -s -G -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data-urlencode "filter=state=ACTIVE" \
  --data-urlencode "pageSize=1000" \
  "https://REGION-integrations.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/integrations/-/versions" \
| jq -r '.integrationVersions[]
         | [ .name, (.runAsServiceAccount // "NONE") ]
         | @tsv'

Remplacez les éléments suivants :

• REGION : région de votre intégration. Pour obtenir la liste des régions compatibles, consultez la section Emplacements.
• PROJECT_ID : ID de votre projet Google Cloud

• Une ligne affichant NONE ne nécessite une action que si la première moitié s'applique également à elle too.
• Pour vérifier une seule intégration, ouvrez-la dans la Google Cloud console et consultez le Résumé de l'intégration volet d'informations dans la barre d'outils d'intégration.

Attention : Conservez filter=state=ACTIVE dans la requête plutôt que de filtrer la sortie par la suite. Le caractère générique - renvoie une version par intégration (la plus récemment modifiée). Par conséquent, si vous récupérez tout et filtrez ultérieurement, toute intégration dont la version la plus récente est un brouillon non publié est supprimée des résultats, même si elle comporte une version publiée qui est toujours en cours d'exécution. Si la réponse contient un nextPageToken, répétez la requête avec pageToken=TOKEN jusqu'à ce que le jeton cesse de revenir.

Mettre à jour vos intégrations

Attribuer le rôle Utilisateur du compte de service

Pour attribuer le rôle à une personne, exécutez la commande suivante :

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT \
    --project=SERVICE_ACCOUNT_PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/iam.serviceAccountUser'

Remplacez les éléments suivants :

• SERVICE_ACCOUNT : adresse e-mail du compte de service d'exécution ou du compte nommé dans un profil d'authentification
• SERVICE_ACCOUNT_PROJECT_ID : ID du projet propriétaire du compte de service
• PRINCIPAL : adresse e-mail de l'utilisateur

Pour les autres types de comptes principaux, utilisez le préfixe --member correspondant :

• Groupes : utilisez group:. Nous vous recommandons d'utiliser des groupes Google plutôt que des comptes utilisateur individuels pour simplifier la gestion des accès lorsque les membres de l'équipe changent.
• Comptes de service : utilisez serviceAccount: pour les processus automatisés et applications.

Attention : L'indicateur --project doit nommer le projet propriétaire du compte de service. Si votre compte de service d'exécution se trouve dans un projet différent de celui de l'intégration, l'attribution appartient au projet du compte de service's projet. L'attribution dans le projet de l'intégration n'aura aucun effet. Il s'agit de l'erreur la plus courante lors de cette modification.

Pour effectuer la même opération dans la Google Cloud console :

1. Accédez à IAM et administration > Comptes de service.
2. Sélectionnez le compte de service.
3. Cliquez sur Autorisations > Accorder l'accès.

Pour en savoir plus, consultez la section Gérer l'accès aux comptes de service.

Définir un compte de service d'exécution

1. Choisissez ou créez le compte de service, puis attribuez-lui les rôles dont les tâches d'intégration ont besoin sur les ressources qu'elles touchent. Pour déterminer ce qu'il faut accorder, examinez les rôles l'agent de service Application Integration de votre projet, service-PROJECT_NUMBER@gcp-sa-integrations., détient aujourd'hui, et n'accordez au nouveau compte que la partie utilisée par cette intégration.
2. Attribuez le rôle Utilisateur du compte de service à tous ceux qui exécutent, approuvent, modifient ou publient l'intégration, y compris toute automatisation.
3. Ouvrez l'intégration et définissez le compte de service dans le Résumé de l'intégration volet d'informations dans la barre d'outils d'intégration.
4. Publiez l'intégration. Pour en savoir plus, consultez la section Tester et publier des intégrations.

Google Cloud recommande d'utiliser un compte de service dédié et à portée minimale pour chaque intégration plutôt qu'un compte à privilèges étendus partagé entre toutes les intégrations, car il effectue les opérations suivantes :

• Contient l'effet d'une intégration.
• S'affiche par son nom dans vos journaux d'audit.

Pour en savoir plus, consultez la section Bonnes pratiques pour l'utilisation des comptes de service.

Résoudre les problèmes d'autorisations manquantes

Une action refusée a l'une des deux causes suivantes, et il est important de les distinguer :

• Le compte de service d'exécution : soit vous ne pouvez pas agir en son nom, soit il ne peut pas atteindre ce dont une tâche a besoin.
• Votre propre rôle IAM : vous n'êtes pas autorisé à effectuer l'action du tout.

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

Erreurs de compte de service d'exécution

Situation	Résultat	Que devez-vous faire ?
Une personne déclenche une intégration, mais ne peut pas agir en tant que compte de service d'exécution	Le déclencheur est refusé avec PERMISSION_DENIED. La vérification s'exécute avant la mise en file d'attente de l'exécution. Par conséquent, rien n'apparaît dans vos journaux d'exécution. On dirait qu'il ne s'est rien passé, plutôt qu'une tâche a échoué.	Attribuez le rôle Utilisateur du compte de service à la personne qui le déclenche.
Une exécution sans identifiants utilisateur ne possède pas de compte de service d'exécution	Les tâches des connecteurs, de l'appel du point de terminaison REST et des fonctions Cloud Run échouent sur tout ce qu'elles tentent d'atteindre. Lors de la publication : The integration is missing run-as service account since governance is enabled for your project.	Définissez un compte de service d'exécution.
Une tâche utilise un profil d'authentification dont le compte de service ne peut pas être utilisé par l'appelant	Cette tâche est refusée tandis que le reste de l'exécution se poursuit : You do not have permission to use Auth Config ID because you cannot act as its service account: SERVICE_ACCOUNT.	Attribuez le rôle Utilisateur du compte de service au compte nommé dans le profil.
Un approbateur ne peut pas agir en tant que compte de service d'exécution	Le processus d'approbation échoue silencieusement sans générer d'erreur visible. L'exécution reste en pause jusqu'à son expiration. Vous remarquez donc que les approbations semblent avoir cessé de fonctionner.	Attribuez le rôle Utilisateur du compte de service à tous ceux qui peuvent approuver.
Une personne modifie ou publie une intégration sans l'autorisation	Publisher does not have required permission to publish integration with service account: SERVICE_ACCOUNT. Tout ce qui est déjà publié continue de s'exécuter. Si l'automatisation publie pour vous, cela apparaît dans votre pipeline de déploiement plutôt que dans la console.	Attribuez le rôle Utilisateur du compte de service aux éditeurs, aux éditeurs, 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	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 d'exécution qui y a déjà accès. Il s'agit généralement de 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 d'Application Integration, consultez la section Codes d'erreur.

Avertissement : Vérifiez de manière proactive vos intégrations programmées et basées sur des événements. Étant donné que ces intégrations s'exécutent automatiquement, les échecs ne déclenchent pas d'avertissements dans la console. Si la programmation est peu fréquente, l'intégration peut ne pas s'exécuter du tout avant que la modification ne prenne effet.

Erreurs de rôle IAM

En plus du compte de service d'exécution, Application Integration vérifie vos autorisations IAM utilisateur pour chaque action. Si vous rencontrez une PERMISSION_DENIED erreur 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 avez besoin de l'un de ces rôles
Afficher et ouvrir des 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 : L'approbation ou la reprise d'une exécution suspendue nécessite l'autorisation integrations.suspensions.resolve que le rôle roles/integrations.integrationEditor n'inclut pas. Les approbateurs ont besoin du rôle roles/integrations.suspensionResolver, ainsi que du rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) sur le compte de service d'exécution.

Remarque : Aucun de ces rôles ne vous permet de modifier les personnes ayant accès. L'attribution des rôles et des autorisations décrits sur cette page nécessite un rôle distinct :

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

Les propriétaires de projet détiennent les deux. Si vous ne pouvez pas effectuer une attribution vous-même, demandez à un administrateur qui le peut.

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 que chacun contient.
• Contrôle des accès, pour savoir comment Application Integration utilise IAM.

Attention : Si votre organisation dé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 association de rôle qui accorde l'accès à une intégration peut refuser l'accès à une autre. Si vous rencontrez des erreurs d'autorisation alors que vous disposez du rôle approprié, vérifiez les conditions associées à votre association de rôle.

Questions fréquentes

J'ai attribué le rôle, mais il échoue toujours. Qu'est-ce qui m'échappe ?

• 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 qui possède l&#101}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 d'exécution et le compte de service de chaque profil d'authentification sont distincts, et les deux ont besoin de l'attribution.
• Le bloc est votre propre rôle, et non le compte de service. Le rôle Utilisateur du compte de service indique si vous pouvez agir en tant que compte de service d'exécution. Un rôle IAM distinct détermine si vous êtes autorisé à effectuer l'action. Consultez la section Erreurs de rôle IAM.

Pourquoi le rôle "Appelant d'intégration" ne suffit-il plus ?

Il vous permet toujours d'exécuter l'intégration. Ce qu'il n'a jamais fait, c'est vous permettre d'agir en tant que compte de service sous lequel l'intégration s'exécute, et c'est ce qui détermine le niveau d'accès de l' exécution. Aucun des rôles suivants n'accorde iam.serviceAccounts.actAs. Il s'agit donc toujours d'une attribution distincte :

• roles/integrations.integrationAdmin
• roles/integrations.integrationEditor
• roles/integrations.integrationInvoker

Mon intégration ne s'exécute que de manière synchrone. Ai-je besoin d'un compte de service d'exécution ?

Non. Une exécution synchrone possède déjà une identité : la personne qui l'a déclenchée. Consultez la section Déterminer si une intégration en a besoin.

Rien n'est signalé dans la console. Tout est-il en ordre ?

Pas forcément. Les avertissements dépendent en partie des exécutions observées. Par conséquent, une intégration avec une programmation peu fréquente ou une intégration que personne n'a déclenchée récemment peut nécessiter une action sans jamais afficher d'avertissement. Consultez la section Intégrations nécessitant un compte de service d'exécution plutôt que de considérer une console silencieuse comme un signal de sécurité.

Étape suivante

• Consultez les consignes de sécurité d'Application Integration.
• Consultez les rôles IAM prédéfinis pour Application Integration.
• Découvrez comment configurer des profils d'authentification.
• Consultez les bonnes pratiques pour l'utilisation des comptes de service.