跨GCP项目通过Dataflow消费Pub/Sub消息的权限配置方法

问题根因 #

本地运行流水线时鉴权主体是你的个人账号，该账号已具备目标Pub/Sub订阅的访问权限，因此可以正常消费；部署到PROJECT B的Dataflow服务后，作业默认使用PROJECT B侧的Dataflow运行时服务账号作为鉴权主体，该主体未被授予PROJECT A内Pub/Sub资源的对应访问权限，因此触发PERMISSION DENIED错误。 #

PROJECT A侧（持有Pub/Sub订阅的项目）配置步骤 #

• 先确认目标Pub/Sub订阅的完整资源路径，格式固定为projects/PROJECT_A/subscriptions/[你的订阅ID]，后续所有权限配置不要误用主题路径替代订阅路径，消费权限是订阅维度的，不是主题维度的。
• 确认PROJECT B侧Dataflow作业使用的服务账号：如果没有自定义配置，默认服务账号格式为service-[PROJECT_B的数字项目编号]@dataflow-service-producer-prod.iam.gserviceaccount.com；如果提交作业时指定了自定义服务账号，就用你指定的自定义账号邮箱即可。
• 给上述服务账号授权，遵循最小权限原则，不要给项目级宽权限：
  • 定位到PROJECT A内的目标Pub/Sub订阅资源，做资源级授权，给服务账号绑定Pub/Sub Subscriber（roles/pubsub.subscriber）角色，该角色自带pubsub.subscriptions.consume、消息ack、调整ack截止时间等消费必需的全部权限。
  • 如果目标订阅开启了CMEK（客户管理加密密钥），还要定位到对应的KMS密钥，给该服务账号绑定Cloud KMS CryptoKey Decrypter（roles/cloudkms.cryptoKeyDecrypter）角色，授予密钥解密权限。
• 检查PROJECT A侧的组织策略限制：如果组织开启了Domain Restricted Sharing（域限制共享）策略，需要把PROJECT B的服务账号加入策略允许列表，否则IAM绑定会不生效。

PROJECT B侧（运行Dataflow作业的项目）配置校验 #

• 确认流水线代码中填写的Pub/Sub订阅路径是PROJECT A的完整路径，不要漏写项目ID，避免出现直接写订阅名、误写为PROJECT B下同名订阅这类低级错误。
• 确认Dataflow作业使用的服务账号，在PROJECT B内已绑定Dataflow Worker（roles/dataflow.worker）角色，否则作业本身无法正常拉起worker节点。
• 如果你使用VPC私有网络部署Dataflow作业，确认子网已开启Private Google Access，避免worker节点无法连通Pub/Sub服务端点——注意这类问题会报网络连通错误，和你当前遇到的权限错误报错特征不同，可以按需排查。

部署验证 #

• 提交Dataflow作业时建议显式指定使用的服务账号，避免误用默认账号，gcloud提交命令参考：

gcloud dataflow jobs run [你的作业名称] \
  --gcs-location gs://[你的Dataflow模板存储路径] \
  --project PROJECT_B \
  --region [作业部署区域] \
  --service-account-email [之前在PROJECT A授权过的服务账号邮箱]

• 作业启动后查看worker日志，如果不再出现PERMISSION DENIED相关报错，且Pub/Sub订阅的未确认消息数持续下降，说明配置生效。
• 如果仍有权限报错，直接用GCP控制台的Policy Troubleshooter功能，分别选择鉴权主体（Dataflow用的服务账号）、目标资源（PROJECT A的Pub/Sub订阅）、操作（pubsub.subscriptions.consume），工具会自动定位缺失的权限绑定。

常见踩坑：不少人会把权限绑定到Pub/Sub主题而非订阅上，Pub/Sub的消费操作是直接对接订阅资源的，仅给主题权限完全无法满足消费需求。

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