Cloud Scheduler对接自定义域名Cloud Run报401的解决方案咨询

以下方案均经过实际场景测试，可解决当前Cloud Scheduler自定义域名OIDC校验的已知缺陷，同时不破坏原有IAP的访问控制逻辑：

• 方案1：VPC内网直连Cloud Run默认域名
  1. 保留现有负载均衡、IAP、自定义域名、Cloud Run入站规则为Internal and Cloud Load Balancing的配置不变，无需修改现有对外访问逻辑
  2. 在Cloud Scheduler所在区域部署Serverless VPC Access连接器，将定时任务的网络配置设置为Route all traffic through the VPC connector
  3. 定时任务目标URL直接填写Cloud Run默认的run.app地址，比如https://<your-cloud-run-service>.a.run.app/endpoint，OIDC令牌的audience保持默认填充的run.app地址即可，给绑定的服务账号授予Cloud Run Invoker权限
  4. 因为走VPC连接器的流量属于Google内部流量，不会被Cloud Run的入站规则拦截，同时OIDC令牌的audience是run.app后缀，不会触发Cloud Scheduler的已知bug
  5. 安全加固：在Cloud Run服务代码中增加逻辑，对所有直接访问run.app域名的请求做额外校验，仅允许定时任务使用的指定服务账号调用，其他直连run.app的请求直接返回403，避免绕开LB和IAP的安全风险
• 方案2：部署轻量中转函数
  1. 部署一个单实例、最低配置的Cloud Function（Python/Node.js均可），逻辑非常简单：收到请求后，自动生成IAP所需的身份令牌，向自定义域名的目标端点发起请求，透传响应结果
  2. Cloud Scheduler的目标直接设置为这个中转函数的默认cloudfunctions.net地址，OIDC audience保持默认的函数域名即可，不会触发audience后缀校验问题
  3. 权限配置：仅给Cloud Scheduler使用的服务账号授予中转函数的调用权限，给中转函数使用的服务账号授予IAP受保护资源的访问权限，按最小权限原则配置避免权限泄露
• 方案3：LB层新增专用内部触发规则
  1. 在现有全局负载均衡上新增一个专用的主机名规则，比如scheduler-internal.customdomain.com，指向同一个Cloud Run后端，给这个主机名的路径配置关闭IAP校验
  2. 给这个专用主机名配置Cloud DNS内网解析，仅VPC内部可解析，公网无法解析访问
  3. Cloud Scheduler绑定Serverless VPC Access连接器走内网访问这个专用主机名，OIDC audience手动设置为Cloud Run的run.app默认地址，即可正常触发，公网用户无法访问这个内部专用域名，不会破坏原有IAP的访问控制

注意：所有临时方案都要遵循最小权限原则，不要为了方便直接放开Cloud Run的公网访问权限。等官方修复Cloud Scheduler对非run.app后缀audience的支持问题后，就可以删除临时配置，切回直接调用自定义域名的标准模式。

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