Cloud Run服务间调用返回403求助（令牌有效角色配置正确）

以下是针对你的场景的具体排查步骤：

1. 核查服务A的入口控制与流量路由逻辑 #

• 服务A设置了内部入口控制+允许外部LB流量，但服务B是直接调用.a.run.app域名而非通过LB，此时只有VPC内的流量才能被允许。需确认服务B的**“将所有流量通过VPC路由”选项已启用**——若未启用，服务B的出站流量会走公网，直接被服务A的内部入口拦截。
• 验证服务B的流量走向：在服务B容器内执行nslookup xxx.a.run.app，若解析到公网IP，说明流量未走VPC，需开启服务B的VPC路由开关。

2. 验证服务账号IAM权限的有效性 #

• 用gcloud命令核对服务A的IAM绑定：

  gcloud run services get-iam-policy SERVICE_A_NAME --region YOUR_REGION
  

  确认输出中包含服务B的服务账号，且已绑定roles/run.invoker角色，绑定范围需覆盖服务A资源（项目级或服务级均可）。

3. 检查令牌的Audience声明 #

• 即使JWT签名合法，若aud（受众）字段与服务A的URL（https://xxx.a.run.app）不匹配，Google前端会直接拦截请求。
• 生成测试令牌并解析验证：

  gcloud auth print-identity-token --audiences=https://xxx.a.run.app --impersonate-service-account=SERVICE_B_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com
  

  将生成的令牌复制到本地JWT解码脚本查看aud字段是否完全匹配服务A的调用地址。

4. 挖掘Cloud Logging中的拦截细节 #

• 服务A的日志未记录请求，说明拦截发生在Google前端，需查看Cloud Run的全局请求日志：
  • 在Cloud Logging中筛选：resource.type="global" AND logName="projects/[YOUR_PROJECT]/logs/run.googleapis.com%2Frequests"
  • 查找对应请求的protoPayload.status和protoPayload.statusDetails字段，其中会明确标注403原因（如“来源IP不在允许列表”“令牌受众不匹配”等）。

5. 临时调整配置做对比验证 #

• 临时将服务A的入口控制改为**“全部”**，保持其他配置不变，用服务B调用.a.run.app：
  • 若调用成功，说明问题根源是服务B的流量未通过VPC到达服务A，需重点排查VPC路由配置；
  • 若仍返回403，需重新核查服务账号权限或令牌生成逻辑。

6. 尝试VPC内服务发现调用方式 #

• 若服务A和B在同一VPC，可尝试用Cloud Run的内部服务发现域名调用：http://SERVICE_A_NAME.SERVICE_A_REGION.run（需确保VPC连接器配置正确且启用了私有服务连接），验证是否能绕过公网拦截。

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