如何在GCP中为Cloud Composer配置自定义域名URL重定向

该方案同时解决自定义域名记忆难、防火墙无法开放*.appspot.com泛白名单的问题。

公网访问场景（官方推荐方案） #

通过Cloud Load Balancing转发流量，同时提供固定公网IP用于防火墙配置：

• 提前准备好自定义域名（如airflow.yourcorp.com），在Google Cloud Certificate Manager中为该域名申请或上传SSL证书。
• 在对应VPC中创建无服务器网络端点组（NEG），后端类型选择Cloud Composer，关联目标Cloud Composer环境，系统会自动绑定对应的AppEngine Airflow Web端点。
• 创建外部HTTP(S)负载均衡：
  • 前端配置固定的公网静态IP，绑定自定义域名和已签发的SSL证书
  • 后端服务关联上一步创建的无服务器NEG，按默认规则配置健康检查
• 到域名注册商后台，将自定义域名的A记录解析到负载均衡的前端静态IP
• 防火墙侧仅需要配置该固定公网IP的访问例外即可，无需开放整个*.appspot.com网段

注意：如果你的Cloud Composer环境开启了IAP访问控制，需要将访问自定义域名的用户、服务账号添加到IAP的Cloud Composer Web User权限列表中，避免出现403错误。

内网私有访问场景 #

如果Airflow服务仅在企业内网开放，可通过内网反向代理实现：

• 在和Cloud Composer同VPC的内网中部署Nginx反向代理实例，为实例绑定固定内网静态IP。
• 配置Nginx反向代理规则，将自定义域名的请求转发到Cloud Composer原生的appspot域名，配置中需要指定Host请求头为原生appspot域名，同时开启SSL证书校验。
• 在企业内网DNS服务器中添加自定义域名的A记录，指向Nginx实例的固定内网IP。
• 防火墙侧仅开放该固定内网IP的访问规则即可，同时可配置Cloud Composer Web访问控制，仅允许Nginx实例IP访问Airflow服务，进一步缩小权限范围。

以上两种方案均不会修改Cloud Composer的原生配置，原有appspot域名的可用性不受影响。

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