我碰到过好几次类似的权限问题，结合你已经完成的配置，下面这些细节很容易被忽略，可以逐一排查：

• 确认Cloud Run服务的 ingress 和身份验证设置
  托管式Cloud Run如果设置了internal-only的 ingress 规则，外部请求（包括Pub/Sub的推送）会直接被拒绝返回403。你可以执行以下命令检查：

  gcloud run services describe $CLOUD_RUN_INSTANCE_NAME --region=europe-your-specific-region
  

  查看输出里的ingress字段，确保它的值是all或者internal-and-cloud-load-balancing；同时确认authentication字段为REQUIRED——这是IAM授权生效的前提。

• 核对Pub/Sub订阅的OIDC令牌受众（Audience）
  Pub/Sub推送的OIDC令牌里的aud参数必须和Cloud Run服务的完整URL（包括https://前缀）完全匹配。你可以通过订阅描述命令检查：

  gcloud pubsub subscriptions describe $app_subscription
  

  找到pushConfig.oidcToken.audience字段，如果它的值不是你的Cloud Run服务URL，赶紧更新：

  gcloud pubsub subscriptions update $app_subscription --push-config-oidc-token-audience=https://<your-cloud-run-full-url>
  

• 验证Pub/Sub服务账号的Token Creator权限范围
  你提到已经配置了Service Account Token Creator权限，要确认是给Pub/Sub的默认服务账号（格式为service-<你的项目编号>@gcp-sa-pubsub.iam.gserviceaccount.com）授予了针对cloud-run-pubsub-invoker服务账号的roles/iam.serviceAccountTokenCreator角色。可以用下面的命令检查绑定关系：

  gcloud iam service-accounts get-iam-policy cloud-run-pubsub-invoker@$PROJECT_NAME.iam.gserviceaccount.com
  

  如果没看到Pub/Sub服务账号的相关绑定，就需要重新添加权限。

• 检查Cloud Run日志的错误细节
  403只是一个笼统的错误，日志里会有更具体的原因——比如令牌受众不匹配、权限缺失、请求来源被拦截等。去Cloud Console的Cloud Run服务日志页面，筛选Pub/Sub推送的请求日志（可以用pubsub.googleapis.com作为关键词），查看statusDetails或者message字段里的具体错误信息，这能帮你直接定位问题。

• 确认推送端点URL的准确性
  虽然你说已经指向了Cloud Run地址，但还是要检查URL是否完全正确：有没有拼错服务名称、区域后缀（比如欧洲区的europe-west1.run.app）？有没有多余的路径或者拼写错误？哪怕一个字符错了，都可能导致权限验证失败。

如果以上排查都没问题，建议把Cloud Run日志里的具体错误信息贴出来，这样能更精准地分析问题。

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