Cloud Run部署后调用Pub/Sub出现403权限拒绝错误（本地运行正常）

这种本地测试正常、部署到Cloud Run就触发权限拒绝的情况确实挺闹心的，尤其是还有一个环境能正常跑，更让人摸不着头脑。结合你的描述，我整理了几个优先级较高的排查方向，你可以一步步试试：

一、确认Cloud Run关联的服务账号及实际生效权限 #

有时候控制台显示的权限可能存在延迟，或者你以为绑定的权限其实没真正生效。可以通过命令行直接验证：

• 检查服务账号在项目下的所有绑定角色：

  gcloud projects get-iam-policy YOUR_PROJECT_ID \
    --filter="bindings.members:serviceAccount:YOUR_CLOUD_RUN_SA@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
    --format="value(bindings.role)"
  

  确保能看到roles/pubsub.publisher、roles/pubsub.editor（或者包含所需权限的自定义角色）。
• 同时确认Cloud Run当前使用的服务账号是否正确：在Cloud Run控制台的「修订版本」详情页，查看「服务账号」字段，是不是你配置了Pub/Sub权限的那个账号——有时候部署时没指定--service-account参数，会默认使用Compute Engine服务账号，这就会导致权限不匹配。

二、检查目标Pub/Sub Topic的IAM绑定 #

别只盯着服务账号的权限，也要确认Topic本身是否给该服务账号开放了权限：

• 查看Topic的IAM配置：

  gcloud pubsub topics get-iam-policy YOUR_TOPIC_NAME \
    --project=YOUR_PROJECT_ID \
    --filter="bindings.members:serviceAccount:YOUR_CLOUD_RUN_SA@YOUR_PROJECT_ID.iam.gserviceaccount.com"
  

  确保返回结果里包含roles/pubsub.publisher角色。如果服务账号只有项目级的Pub/Sub权限，但Topic设置了更严格的IAM规则（比如拒绝了该账号），也会触发403。

三、排查IAM权限的传播延迟 #

GCP的IAM权限不是实时生效的，尤其是跨资源的权限变更，可能需要5-15分钟才能完全同步到所有服务。如果你是刚给服务账号加的权限，不妨等一段时间后重新部署Cloud Run再测试——低环境可能刚好是等够了生效时间才测试成功的，而当前环境没等够就测试了。

四、确认代码中的资源路径是否正确 #

虽然你说代码和本地一致，但不同环境的配置可能存在差异：

• 在Cloud Run的日志里打印topic_path的值，确认是不是指向当前环境的正确项目ID和Topic名称。比如有没有把低环境的项目ID硬编码到代码里，或者Topic名称写错了？

五、检查网络配置差异 #

如果当前环境的Cloud Run配置了VPC连接器，对比低环境的VPC设置：

• 是不是防火墙规则阻止了Cloud Run访问Pub/Sub的公共端点？
• 有没有启用Private Service Connect，但没正确配置Pub/Sub的私有访问？
  这些网络层面的限制也会导致看似权限正常，但实际无法访问Pub/Sub服务。

另外提个小细节：你的代码里没有指定密钥文件，是用的默认应用凭据，这在Cloud Run里是正确的做法——不需要额外挂载服务账号密钥，Cloud Run会自动关联指定的服务账号凭据，所以不用在代码里做额外配置。

先从上面这几点排查，大概率能找到问题所在。

备注：内容来源于stack exchange，提问作者Aswin