欢迎光临
我们一直在努力
        找回密码
当前位置：171主机测评 > 服务器技术 > 正文

突破 GCP 企业合规限制：基于 Google cloud API Gateway 的 Cloud Run 鉴权转换方案

2026-06-04 分类：服务器技术 阅读(29) 评论(0)

突破 GCP 企业合规限制：基于 API Gateway 的 Cloud Run 鉴权转换方案

作者：Jason Poon 标签：GCP, Cloud Run, API Gateway, Serverless, IAM, 架构设计

1. 背景：企业级安全策略下的访问隔离

在 Google Cloud Platform (GCP) 中，Cloud Run 是 Serverless 容器托管的核心组件。在标准场景下，开发者通常通过赋予 allUsers 权限来对外暴露服务。

然而，在企业级生产环境（如跨国金融机构的 GCP 基础设施中），面临严格的合规审计与组织策略（Org Policy）约束，Cloud Run 服务通常被绝对禁止暴露于公网，必须强制配置 –no-allow-unauthenticated 参数。

由此产生架构痛点：托管在内部 Cloud Run 上的服务（如前端 SPA 或外部调用的轻量级 API），应如何在受限环境下向合法外部客户端提供访问入口？

前期，本团队曾通过 GCE + Envoy 结合 gcp_authn C++ 插件的方式，构建代理节点手动签发 Token 来解决此问题（详见：《硬核破局！Envoy 编译 gcp_authn 插件：以网关身份动态换取 GCP Identity Token 代理访问受限 Cloud Run》）。然而，自建 Envoy 代理带来了较高的计算资源与运维负担。本文将介绍一种更为云原生、免运维的 Serverless 替代方案，即利用 Google API Gateway 实现原生的鉴权转换。

2. 架构瓶颈：前后端分离场景下的鉴权困境

针对受限的 Cloud Run，GCP 官方提供两种标准访问模式：

  • Google Identity-Aware Proxy (IAP)：通过 IAP 实现应用级访问控制。
    • 局限性：IAP 通常与企业 Google Workspace 域（如 @company.com）深度绑定。对于域外终端用户或 B2B API 调用，IAP 鉴权链路存在阻碍，缺乏灵活性。
  • Identity Token 鉴权：在 HTTP Header 中提供合法的 Authorization: Bearer <GCP_Identity_Token>。
    • 局限性：在前后端分离架构下，前端 JS 运行于用户侧浏览器。客户端无法、也不应持有 GCP Service Account 密钥文件以自行签发 Token。

    • 由此形成架构冲突：客户端无法持有凭证，而底层服务拒绝无凭证访问。

    3. 解决方案：API Gateway Token Exchange 架构

    为解决无状态客户端访问内部服务的问题，我们引入 Google Cloud API Gateway 作为前置反向代理层。

    核心架构设计

    Architecture Diagram

    通过引入 API Gateway，将 Token 签发逻辑由客户端后置至网关层：

  • 将 API Gateway 暴露至公网，作为流量的统一入口。
  • 为网关实例绑定特定的 Service Account (SA)。
  • 客户端发起无状态的常规 HTTP 请求。
  • 鉴权转换 (Token Exchange)：网关拦截请求，使用绑定的 SA 动态向 GCP IAM 换取临时 Identity Token，并将其注入 HTTP Authorization Header，随后转发至后端 Cloud Run。
  • Cloud Run 校验 Token 有效性，放行请求并返回业务响应。

    • 4. 工程实践：端到端配置指南

    以下为实现鉴权转换的 Terraform / gcloud 操作路径。

    步骤一：部署受限的 Cloud Run 服务

    部署应用时，显式拒绝所有未经认证的请求：

    gcloud run deploy cr-webui \\
    –image europe-west2-docker.pkg.dev/my-project/my-repo/webui:latest \\
    –service-account=cr-webui-runtime-sa@my-project.iam.gserviceaccount.com \\
    –no-allow-unauthenticated \\
    –region europe-west2

    此时通过公网直接访问原生 URL 将返回 HTTP 403 Forbidden。

    步骤二：配置网关专属 Service Account

    创建网关运行标识，并授予其调用目标 Cloud Run 的 IAM 权限：

    # 创建网关 Service Account
    gcloud iam service-accounts create gateway-invoker –project=my-project

    # 授予 run.invoker 角色
    gcloud run services add-iam-policy-binding cr-webui \\
    –member="serviceAccount:gateway-invoker@my-project.iam.gserviceaccount.com" \\
    –role="roles/run.invoker" \\
    –region=europe-west2 \\
    –project=my-project

    步骤三：定义 OpenAPI 路由规范

    API Gateway 的路由分发与后端鉴权逻辑由 OpenAPI 2.0 (Swagger) 规范驱动。

    swagger: '2.0'
    info:
    title: CR–WebUI API Gateway
    description: Gateway to proxy requests with Identity Token exchange
    version: 1.0.0
    schemes:
    – https

    paths:
    /:
    get:
    summary: "Root Web UI"
    operationId: "getRoot"

    # x-google-backend 为 GCP API Gateway 的私有扩展
    x-google-backend:
    address: "https://cr-webui-7hq3m4pdya-nw.a.run.app"
    path_translation: APPEND_PATH_TO_ADDRESS

    responses:
    '200':
    description: "OK"

    /**:
    # 通配符路由：处理静态资源与子路径请求
    get:
    operationId: "proxyGet"
    x-google-backend:
    address: "https://cr-webui-7hq3m4pdya-nw.a.run.app"
    path_translation: APPEND_PATH_TO_ADDRESS
    responses:
    '200':
    description: "OK"

    配置中的 x-google-backend 扩展是核心所在，它触发网关底层的 Token 获取机制并将请求重定向至目标 address。

    GCP API Gateway Config 图：GCP 控制台中解析后的 OpenAPI 规范

    步骤四：部署 API Gateway 实例

    应用配置并拉起网关实例：

    # 1. 创建 API
    gcloud api-gateway apis create cr-webui-api –project=my-project

    # 2. 创建 API Config，绑定 OpenAPI 规范与目标 SA
    gcloud api-gateway api-configs create cr-webui-config-v1 \\
    –api=cr-webui-api \\
    –openapi-spec=openapi.yaml \\
    –project=my-project \\
    –backend-auth-service-account=gateway-invoker@my-project.iam.gserviceaccount.com

    # 3. 部署 Gateway
    gcloud api-gateway gateways create cr-webui-gw \\
    –api=cr-webui-api \\
    –api-config=cr-webui-config-v1 \\
    –location=europe-west2 \\
    –project=my-project

    5. 验证与抓包分析

    部署完成后，网关将获得一个 .gateway.dev 后缀的公网入口。本实验的最终公网访问入口为：https://cr-webui-gw-bn1ehv9s.nw.gateway.dev。

    GCP API Gateway List 图：API Gateway 分配的默认域名

    5.1 鉴权与 Token 注入验证

    通过浏览器直接访问该网关 URL，请求成功响应 HTTP 200。在后端的 HTTP Headers 审查中（Token Inspector 页面），可以清晰地看到网关在底层自动换取并注入的 Identity Token：

    Token Inspector 图：后端成功接收到网关代发注入的 Bearer Token

    解析这段长长的 JWT，其 email 字段的值确切地指向了我们绑定的 gateway-invoker@my-project.iam.gserviceaccount.com。这验证了外部无状态请求在途经 API Gateway 时，已成功完成身份转换，穿透了 Cloud Run 的 IAM 安全策略限制。

    5.2 子路径代理验证

    除了根路径，得益于 OpenAPI 规范中 /** 通配符路由与 APPEND_PATH_TO_ADDRESS 特性的配置，网关同样能完美代理后端的任意子路径（如 FastAPI 原生的 /docs 接口）及其关联的底层静态资源（JS/CSS）请求：

    FastAPI Docs 图：网关完美代理后端的 Swagger UI 及其静态资源

    6. 架构探讨与最佳实践

    Q1: 如何为 API Gateway 配置自定义域名？

    API Gateway 实例默认不支持直接绑定自定义 DNS 记录。如需配置自定义域名（如 api.company.com），需在网关前沿部署 Google Cloud 外部应用负载均衡器 (External Application Load Balancer)，通过创建 Serverless NEG (网络端点组) 将网关作为后端接入，并由负载均衡器完成 SSL 卸载与域名路由。

    Q2: 内部微服务 (Cloud Run to Cloud Run) 是否应通过 Gateway 调用？

    不建议。 如果调用方同为 GCP 内部的 Cloud Run 服务，其已具备运行时 Service Account。最佳实践是让调用方在代码级直接请求 GCP Metadata 服务，获取目标 Audience 的 Identity Token 后发起点对点 (P2P) 请求。在此场景下引入 API Gateway 会导致不必要的网络跳数、延迟及额外成本。 进一步的隔离要求可通过 VPC Connector 配置 Direct VPC Egress 实现纯内网流量控制。

    总结

    在 GCP Serverless 生态中，API Gateway 配合 x-google-backend 扩展有效调和了企业安全合规与业务接入灵活性之间的矛盾。该方案大幅降低了前置鉴权与反向代理的运维复杂度，是企业级云原生架构中的标准实践。

    赞(0)
    未经允许不得转载：171主机测评 » 突破 GCP 企业合规限制：基于 Google cloud API Gateway 的 Cloud Run 鉴权转换方案
    分享到： 更多 (0)
    标签：

    相关推荐

    评论 抢沙发

    取消

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址

    热门标签

    #人工智能(58419)#python(19839)#开发语言(16678)#java(15321)#运维(15238)#linux(14850)#大数据(14433)#服务器(12970)#算法(11674)#前端(10771)#网络(9280)#数据库(8804)#ai(8753)#c++(8098)#课程设计(6775)#学习(6698)#机器学习(6642)#区块链(5868)#OpenClaw(5384)#后端(5092)#spring boot(4976)#深度学习(4878)#c语言(4347)#毕业设计(4286)#数据结构(4166)#安全(4000)#docker(3906)#架构(3816)#javascript(3781)#大模型(3613)

    热门文章

    最新文章

    归档

    分类