Airflow Glue Operator的iam_role_name参数无效问题咨询

1. 参数设计逻辑的误解 #

iam_role_name并非用来让Airflow（MWAA服务角色）切换角色调用Glue API，它的作用是把指定角色传递给Glue的StartJobRun API，让Glue Job本身以该角色执行。这个参数要生效必须满足两个硬条件：

• MWAA的服务角色必须拥有iam:PassRole权限，且权限资源明确指向你的目标Glue角色ARN
• 目标Glue角色的信任策略必须允许glue.amazonaws.com作为信任实体（也就是Glue服务能assume这个角色）

如果缺了其中任何一个，AWS会拒绝Glue使用指定角色，转而用调用者（MWAA服务角色）的权限执行，这就是你看到的“任务以Airflow角色运行”的原因。

2. 特定版本的Provider缺陷 #

在你使用的apache-airflow-providers-amazon==2.4.0版本中，AwsGlueJobOperator对iam_role_name的处理存在两个问题：

• 若你的Glue Job已经在AWS控制台预先配置了执行角色，该参数无法正确覆盖原有配置
• Hook代码中存在参数传递逻辑漏洞，导致RoleName无法正确传入Glue API请求

3. MWAA的权限边界限制 #

MWAA的服务角色默认没有iam:PassRole权限，而且AWS对MWAA的权限管控比较严格。即使你传了iam_role_name，只要MWAA角色没权限把这个角色“递给”Glue，AWS会直接忽略该参数， fallback到使用调用者角色执行。

可行解决方案（对应AWS支持给出的选项） #

• 创建关联Glue角色的Airflow连接：通过连接配置指定要assume的角色，让Airflow在调用Glue API前先切换到该角色，此时Glue Job会默认使用该角色执行，无需依赖iam_role_name参数
• 为MWAA角色补充权限：给MWAA服务角色添加iam:PassRole权限（资源设为目标Glue角色的ARN），同时确保Glue角色的信任策略允许Glue服务assume它，这样iam_role_name参数就能正常生效
• 使用AWS提供的自定义Operator：该Operator通过更严谨的角色切换逻辑，实现任务级别的权限隔离，适合需要严格管控每个任务权限的场景

内容的提问来源于stack exchange，提问作者Dommondke