为什么应用 API Gateway 后 Cloud Run URL 仍然可以访问？答案

【问题标题】：Why is the Cloud Run URL still accessible after API Gateway applied?为什么应用 API Gateway 后 Cloud Run URL 仍然可以访问？
【发布时间】：2021-06-09 03:29:58
【问题描述】：

我使用 opeanapi yaml 文件作为配置应用了 Google 的 API 网关，并收到了新的网关 URL。

我的问题是，如果原始 Cloud Run URL 仍可访问，网关的意义何在？

我可以对网关 URL 和 Cloud Run URL 进行完全相同的 Postman 调用，例如 https://gateway.api.url.google.com/orders 和 https://cloud.run.url.google.com/orders.

我的假设（和希望）是网关 URL 现在是主 URL，对 Cloud Run URL 的任何请求都会路由到 API 网关。任何人都可以对此有所了解吗？

【问题讨论】：

标签： google-cloud-run api-gateway google-api-gateway

【解决方案1】：

API 网关只是一个门户（实际上是网关），位于一个或多个 API 前面。 API 网关的目标是将来自不同后端的 API 端点集中在一个地方，并为消费者提供一致的体验（安全性、域名等）

API 网关位于多个后端之前，但无论如何都会更改这些后端的行为。因此，它们仍然可以通过 API 网关直接访问。

如果你不想要这个，我可以为你推荐 2 个解决方案

将您的 Cloud Run 服务设置为私有（我的意思是使用 --no-allow-unauthenticated 参数部署它，或者删除 allUsers 访问权限）。像这样，只有经过身份验证的请求者才能访问它。在 API Gateway 中，设置custom service account，并仅授予此服务帐户roles/run.invoker 角色。最后，只有 API 网关才能调用 Cloud Run 服务。所有直接调用，无论是否经过身份验证，都将被拒绝，因为只有 API Gateway 有权访问它。
如果您的 API Gateway OpenApi 配置中没有特殊功能，您可以改用a HTTPS Load balancer in front of your Cloud Run services。并将Cloud Run ingress 参数设置为internal-and-cloud-load-balancing

【讨论】：

对不起，答案没有解决问题。希望它做到了。也许我没有正确表达这个问题。简单地说 - 如果应用了网关，为什么仍然可以访问 Cloud Run URL？
因为 API Gateway 是一个附加层，不会更改 Cloud Run 的当前配置。这就像将前端（在 JavaScript 中）放在 REST API 后端之前。后端仍然可以直接访问，也可以通过前端访问。