Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Comment Step Functions génère des politiques IAM pour les services intégrés
Lorsque vous créez une machine à états dans la AWS Step Functions console, Step Functions produit une politique Gestion des identités et des accès AWS (IAM) basée sur les ressources utilisées dans la définition de votre machine à états, comme suit :
+ Pour **des intégrations optimisées**, Step Functions créera une politique avec toutes les autorisations et tous les rôles nécessaires pour votre machine d'état.
Conseil : Vous pouvez consulter des exemples de politiques dans chacune des pages de service ci-dessous[Intégrer des services optimisés](integrate-optimized.md).
+ Pour les **intégrations standard**, Step Functions créera un rôle IAM avec des autorisations partielles.
Vous devez ajouter toutes les politiques de rôle manquantes dont votre machine d'état a besoin pour interagir avec le service.
## Ressources dynamiques et statiques
Les *ressources statiques* sont définies **directement** dans l'état des tâches de votre machine d'état. Lorsque vous incluez les informations relatives aux ressources que vous souhaitez appeler directement dans l'état de vos tâches, Step Functions peut créer un rôle IAM uniquement pour ces ressources.
Les *ressources dynamiques* sont **transmises** en entrée lors du démarrage de votre machine à états, ou en entrée dans un état individuel, et accessibles à l'aide de JSONata ou JSONPath a. Lorsque vous transmettez des ressources dynamiques à votre tâche, Step Functions ne peut pas automatiquement réduire les autorisations. Step Functions créera donc une politique plus permissive qui spécifie :. `"Resource": "*"`
## Autorisations supplémentaires pour les tâches utilisant .sync
Les tâches qui utilisent le modèle [Run a Job (.sync)](connect-to-resource.md#connect-sync) nécessitent des autorisations supplémentaires pour surveiller et recevoir une réponse de l'API des services connectés.
Step Functions utilise deux approches pour surveiller le statut d'une tâche lorsqu'elle est exécutée sur un service connecté : les **sondages** et les **événements**.
Le sondage nécessite une autorisation pour les `Describe` actions `Get` d'API. Par exemple, pour Amazon ECS, la machine d'état doit disposer d'une autorisation d'autorisation pour`ecs:DescribeTasks`, car AWS Glue la machine d'état nécessite des autorisations d'autorisation pour`glue:GetJobRun`. Si les autorisations nécessaires ne sont pas associées au rôle, Step Functions ne sera peut-être pas en mesure de déterminer le statut de votre tâche. L'une des raisons de l'utilisation de la méthode de sondage est que certaines intégrations de services ne prennent pas en charge les EventBridge événements et que certains services n'envoient des événements que dans la mesure du possible.
Vous pouvez également utiliser des événements envoyés par les AWS services à Amazon EventBridge. Les événements sont acheminés vers Step Functions EventBridge via une règle gérée, de sorte que le rôle nécessite des autorisations pour `events:PutTargets``events:PutRule`, et`events:DescribeRule`. Si ces autorisations sont absentes du rôle, Step Functions peut prendre un certain temps avant que Step Functions ne soit informée de la fin de votre tâche. Pour plus d'informations sur les EventBridge événements, consultez la section [Événements liés AWS aux services](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-service-event.html).
## Résolution des problèmes liés aux flux de travail .sync bloqués
Pour les tâches Run a Job (.sync) qui prennent en charge **à la fois les** sondages et les événements, votre tâche peut s'exécuter correctement en utilisant des événements, même si le rôle ne dispose pas des autorisations requises pour les sondages.
Dans le scénario précédent, vous ne remarquerez peut-être pas que les autorisations de sondage sont manquantes ou incorrectes. Dans les rares cas où un événement ne parvient pas à être transmis ou traité par Step Functions, votre exécution peut être bloquée.
Pour vérifier que vos autorisations d'interrogation sont correctement configurées, vous pouvez exécuter une exécution dans un environnement sans EventBridge événements en procédant comme suit
+ Supprimez la règle gérée chargée de transférer les événements vers Step Functions. EventBridge
**Note**
Les règles gérées étant partagées par toutes les machines d'état de votre compte, vous devez utiliser un compte de test ou de développement pour éviter tout impact involontaire sur les autres machines d'état.
+ Vous pouvez identifier la règle gérée spécifique à supprimer en inspectant le `Resource` champ utilisé `events:PutRule` dans le modèle de politique du service cible. La règle gérée sera recréée la prochaine fois que vous créerez ou mettrez à jour une machine à états utilisant cette intégration de services.
+ Pour plus d'informations sur la suppression de EventBridge règles, consultez la section [Désactivation ou suppression d'une règle](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-delete-rule.html).
## Autorisations pour annuler des flux de travail
Si une tâche utilisant le modèle Run a Job (.sync) est arrêtée, Step Functions fera de son mieux pour annuler la tâche.
L'annulation d'une tâche nécessite l'autorisation de`Cancel`, `Stop``Terminate`, ou des actions `Delete` d'API, telles que `batch:TerminateJob` ou`eks:DeleteCluster`. Si ces autorisations ne sont pas associées à votre rôle, Step Functions ne sera pas en mesure d'annuler votre tâche et vous risquez de devoir payer des frais supplémentaires pendant son exécution. Pour plus d'informations sur l'arrêt des tâches, consultez [Run a Job](connect-to-resource.md#connect-sync).
**En savoir plus sur les modèles d'intégration**
Pour en savoir plus sur les tâches synchrones, voir[Découvrez les modèles d'intégration des services dans Step Functions](connect-to-resource.md).