咨询GCP API Gateway前置internal ingress Cloud Run后端的实现方法

现有基础与优化目标 #

• 已在Cloud Run部署运行正常的生产API，原配置为public ingress模式 + 身份授权规则，全链路业务稳定
• 架构优化需求：将Cloud Run的ingress模式调整为internal ingress，彻底阻断所有公网直连Cloud Run容器的流量路径，仅保留前置API Gateway作为唯一对外流量入口
• 现存认知卡点：已知Cloud Run internal ingress的准入要求为仅允许来自受信内部网络/VPC的请求访问，但未在API Gateway的配置项中找到主动关联VPC、从VPC内发起后端请求的对应选项，不确定架构能否跑通

可落地的实现路径 #

• 首先破除认知误区：Cloud Run的internal ingress准入规则，并非强制要求请求必须来自用户自定义的VPC网络，其核心校验逻辑是「拦截所有从公网直接路由到Cloud Run默认域名的请求，仅放行GCP内部受信网络平面转发的合法请求」
• API Gateway的原生适配性：API Gateway本身部署在Google内部受信网络平面，其向后端Cloud Run转发请求的源地址属于Google受信网段，完全满足Cloud Run internal ingress的准入校验规则，不需要额外为API Gateway配置VPC对等连接、Serverless VPC访问等关联VPC的配置
• 配套安全加固配置步骤：
  1. 保留Cloud Run的始终要求身份验证开关，在IAM权限体系中，仅给API Gateway关联的服务账号授予roles/run.invoker调用权限，移除所有其他账号、未授权主体的调用权限
  2. 将Cloud Run的ingress模式从public切换为internal，配置完成后直接通过Cloud Run的默认公网域名发起测试请求，预期会返回403禁止访问的响应，确认直连公网路径完全失效
  3. 从公网侧调用API Gateway对外暴露的域名，全链路测试API转发逻辑，确认请求可以正常透传到后端Cloud Run服务，业务响应无异常
• Beta能力的实际可用性：虽然API Gateway、Cloud Run internal ingress的部分配套能力当前处于Beta阶段，但核心流量转发链路的可靠性、准入规则的稳定性已经经过大规模生产环境验证，不会因为Beta标识导致核心架构失效，仅在控制台交互、边缘能力细节上可能存在版本迭代调整

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