Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Cómo Step Functions genera IAM políticas para servicios integrados
Al crear una máquina de estados en AWS Step Functions consola, Step Functions produce un AWS Identity and Access Management (IAM) política basada en los recursos utilizados en la definición de su máquina de estados, de la siguiente manera:
-
Si su máquina de estados usa una de las integraciones optimizadas, Step Functions creará una política con los permisos y roles necesarios para su máquina de estados. (Excepción: MediaConvert la integración requiere que configure los permisos manualmente; consulteIAMpolíticas de llamadas AWS Elemental MediaConvert.)
-
Si su máquina de estado usa uno de los AWS SDKen las integraciones, se creará un IAM rol con permisos parciales. Después, puede utilizar la IAM consola para añadir las políticas de roles que falten.
Los siguientes ejemplos muestran cómo Step Functions genera una IAM política basada en la definición de la máquina de estados. Elementos del código de ejemplo, como [[resourceName]]
Recursos dinámicos frente a recursos estáticos
Los recursos estáticos se definen directamente en la estado de la tarea de la máquina de estado. Al incluir la información sobre los recursos a los que desea llamar directamente en los estados de las tareas, Step Functions crea un IAM rol solo para esos recursos.
Los recursos dinámicos son los que se transfieren a la entrada del estado y se puede acceder a ellos mediante una ruta (consulte Uso de rutas para acceder a la entrada de los flujos de trabajo de Step Functions). Si pasa recursos dinámicos a una tarea, Step Functions creará una política más privilegiada que especifica: "Resource": "*".
Permisos adicionales para las tareas que utilizan el patrón de ejecución de un trabajo
Para las tareas que utilizan el patrón Run a Job (las que terminan en.sync), se necesitan permisos adicionales para supervisar y recibir una respuesta de las API acciones de los servicios conectados. Las políticas relacionadas incluyen más permisos que las tareas que utilizan los patrones de solicitud de respuesta o espera de devolución de llamada. Consulte Descubra los patrones de integración de servicios en Step Functions para obtener información acerca de las tareas síncronas.
nota
Debe proporcionar permisos adicionales para las integraciones de servicios que admitan el patrón Run a Job (.sync).
Step Functions utiliza dos métodos para supervisar el estado de un trabajo cuando se ejecuta en un servicio conectado: sondeos y eventos.
El sondeo requiere permiso Describe o Get API acciones, como ecs:DescribeTasks o. glue:GetJobRun Si el rol no tiene estos permisos, es posible que Step Functions no pueda determinar el estado del trabajo. Esto se debe a que algunas integraciones del servicio Run a Job (.sync) no admiten EventBridge eventos y algunos servicios solo envían eventos según el mejor esfuerzo.
Eventos enviados desde AWS los servicios a Amazon EventBridge se dirigen a Step Functions mediante una regla gestionada y requieren permisos para events:PutTargetsevents:PutRule, yevents:DescribeRule. Si no tiene estos permisos en el rol, es posible que se produzca un retraso antes de que Step Functions tenga conocimiento de que ha completado el trabajo. Para obtener más información sobre EventBridge los eventos, consulte Eventos de AWS servicios.
nota
En el caso de las tareas de ejecución de un trabajo (.sync) que admiten sondeos y eventos, es posible que la tarea se complete correctamente mediante eventos. Esto puede ocurrir incluso si el rol carece de los permisos necesarios para realizar sondeos En este caso, es posible que no se dé cuenta inmediatamente de que los permisos de sondeos faltan o son incorrectos. En la instancia infrecuente de que Step Functions no entregue o procese el evento, la ejecución podría bloquearse. Para comprobar que sus permisos de sondeo están configurados correctamente, puede ejecutar una ejecución en un entorno sin EventBridge eventos de las siguientes maneras:
-
Elimine la regla gestionada de EventBridge, que es responsable de reenviar los eventos a Step Functions. Todas las máquinas de estado de la cuenta comparten esta regla gestionada, por lo que debe realizar esta acción únicamente en una cuenta de prueba o de desarrollo para evitar cualquier impacto involuntario en otras máquinas de estado. Puede identificar la regla administrada específica que desea eliminar inspeccionando el campo
Resourceutilizado paraevents:PutRuleen la plantilla de política del servicio de destino. La regla administrada se volverá a crear la próxima vez que cree o actualice una máquina de estado que utilice esa integración de servicios. Para obtener más información sobre la eliminación de EventBridge reglas, consulte Desactivar o eliminar una regla. -
Realice pruebas con Step Functions Local, que no admite el uso de eventos para completar las tareas de ejecución de trabajo (.sync). Para usar Step Functions Local, asuma el IAM rol que usa su máquina de estados. Es posible que deba editar la Relación de confianza. Defina las variables de entorno
AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEYyAWS_SESSION_TOKENen los valores del rol asumido y, a continuación, inicie Step Functions Local usando java -jar StepFunctionsLocal.jar. Por último, utilice el AWS CLI con el --endpoint-url parámetro para crear una máquina de estados, iniciar una ejecución y obtener el historial de ejecuciones. Para obtener más información, consulte Probar máquinas de estado localmente en Step Functions.
Si se detiene una tarea que utiliza el patrón de ejecución de trabajo (.sync), Step Functions hará todo lo posible por cancelar la tarea. Esto requiere permiso paraCancel, StopTerminate, o Delete API realizar acciones, como batch:TerminateJob oeks:DeleteCluster. Si la función no tiene estos permisos, Step Functions no podrá cancelar la tarea y podrían acumularse cargos adicionales mientras siga ejecutándose. Para obtener más información, consulte Ejecución de un trabajo.
