同项目同角色服务账号运行Dataflow Flex模板出现poll time out问题

两个服务账号表面绑定角色一致，但实际权限存在隐形差异，是该问题的核心诱因，常见触发场景如下：

• 存储桶权限遗漏/被覆盖：你当前给SA绑定的角色中Storage Object Viewer本身没有GCS存储桶的写入权限，即便绑定了Editor角色，也可能被桶级IAM拒绝策略、组织级拒绝策略覆盖权限。能正常运行的SA大概率单独在目标日志存储桶<LOGGING_BUCKET>上配置了额外的写权限，而失败的SA没有该桶级权限，无法写入结果文件和日志，直接导致轮询超时、作业卡在队列阶段。
• IAM条件限制：失败的SA的角色绑定可能配置了条件规则，比如限制仅能从特定IP调用、仅能访问特定服务，触发Dataflow作业时不符合条件导致权限失效。
• 服务代理授权缺失：Dataflow运行时需要调用Google托管的服务代理模拟用户SA身份执行操作，如果失败的SA没有给Dataflow服务代理授予roles/iam.serviceAccountUser权限，会导致作业无法正常启动。
• 组织策略限制：组织层面的限制策略可能将失败的SA加入了Dataflow使用禁止名单、或者禁止该SA写入对应区域的GCS资源，导致作业启动被拦截。

• 第一步：核对两个SA的有效权限差异，执行以下命令分别查询两个SA的项目级和桶级IAM配置，对比权限差异：
  项目级权限查询：gcloud projects get-iam-policy <你的项目ID> --filter="bindings.members:serviceAccount:<SA邮箱>" --format=json
  日志桶级权限查询：gcloud storage buckets get-iam-policy gs://<LOGGING_BUCKET> --format=json
  重点校验失败的SA是否有storage.objects.create、storage.objects.list两类GCS权限，90%以上的该类问题都是因为缺少这两个权限。
• 第二步：检查失败SA的IAM绑定是否存在条件规则，在GCP控制台IAM页面找到对应SA的角色绑定，查看是否有附加条件，删除不符合Dataflow运行要求的限制条件。
• 第三步：补全服务代理授权，给失败的SA绑定roles/iam.serviceAccountUser角色，成员填写Dataflow服务代理账号（格式为service-<你的项目数字ID>@dataflow-service-producer-prod.iam.gserviceaccount.com）。
• 第四步：排查组织策略限制，在GCP控制台组织策略页面，查询constraints/dataflow.restrictWorkerServiceAccountUsage、constraints/gcp.restrictResourceUsageByServiceAccount两类策略，确认失败的SA不在禁止列表中。
• 第五步：权限修复后验证，给失败的SA在日志存储桶上单独绑定Storage Object Admin角色，重新提交Dataflow Flex模板作业确认运行正常。

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