authentication - 使用 Google Cloud Endpoints 保护 Google Cloud Run 上的内部 API 的最佳方式

Question

场景

我在 Cloud Run 中托管一个我希望保护的 API(grpc，但问题也适用于 http)。目标是提供对我们组织中多个应用程序的访问。请注意，每个应用程序都有多个实例在另一个位置运行(每个外部客户端一个)。该API仅供内部使用，不会被网络浏览器直接访问。

选项

我已经确定了以下选项:

1. 不使用 Cloud Endpoints:我可以将 API 设为非公开并由服务帐户保护。承载 token (id token )可以在应用程序中自动生成。
2. 云端点 + API key :对于每个应用程序，我都会生成一个供该应用程序的所有实例使用的 API key 。这非常容易设置，因为它只需要发送一个额外的 header 。
3. 云端点 + 自签名 jwt:我使用服务帐户生成自签名 token (请参阅 GCP documentation on Service-to-Service communication )，并使用该服务帐户配置端点。多个应用程序要么获得自己的服务帐户，要么我从同一个应用程序生成新 key 。请注意，自签名 token 并非在所有库中都可用，并且需要一些手动工作。因此刷新 token 也是手动的。
4. Cloud Endpoints + Google ID:这仅提供身份验证，不提供授权。这也意味着拥有 Google 帐户的每个人都可以访问我的 API(!)。优点是可以使用简单的工具来生成 ID token 。
5. 云端点 + API key + Google ID
6. 云端点 + API key + 自签名 jwt

问题

1. 哪个选项最适合我的情况？ (欢迎其他选项/建议)
2. 选项 1 通常被认为是安全的吗？如果是这样，为什么还要费心使用云端点呢？
3. Google 文档提到了不同形式的身份验证(请参阅 GCP documentation on Authentication methods )。然而，感觉其中有些是授权(例如 API key 和服务帐户)，有些是身份验证(例如 Google ID)。这是正确的评估吗？
4. 我假设 GCP 了解 3 涉及服务帐号，并且可以以自己的方式验证它们；没有服务帐户 key 的人无法获得访问权限。
5. 在选项 3 中:我认为使用多个服务帐户更好，每个应用程序一个，最好每个实例一个 key 。这会被认为是选项 3 的最佳方式吗？
6. 是否值得在实际 API 中执行额外的验证？如果是这样，为什么我还要拥有云端点？
7. GCP 文档没有提及选项 4 的大问题。我认为这一点应该说得更清楚。
8. 使用选项 5 有什么好处？我可以识别谁调用电话吗？那为什么不制作更多 API key 呢？
9. 选项 6 有用吗？虽然这被认为是云端点中的身份验证，但这实际上是授权，对吗？
10. 如果 API 被网络浏览器访问，会发生什么变化？

Answer 1

这是我的意见(但您的问题是基于意见的，可能会被关闭)

1. 这要看情况!主要是您的客户端应用程序功能!如果您能够基于服务帐户生成 Google 签名的 JWT，那就完美了(不是 Cloud Endpoint，产品的 native 安全性)。 请记住，添加附加层意味着新的可能的故障点、需要维护和更新的新内容。如果你能避免它，那就更好了!

2. 是的，请参阅我之前的问题。如果您的客户端应用程序无法生成动态凭证，您可以使用 API Key 等静态凭证(存在静态凭证的所有问题，如轮换、窃取、过期...)

3. Google 在所有情况下都会执行身份验证。仅针对GCP产品，根据IAM角色和权限进行授权。

4. 对于#3，签名的公钥必须已知。通过服务帐户，Google 知道公钥。您可以配置自定义身份验证，并且可以提供您自己的公钥(例如，如果您使用 self 管理的 OIDC 服务器，则为您的 PKI)

5. 每个应用程序 1 个服务帐户(如果很好):每个应用程序可以拥有不同的权限。如果一个应用程序遭到破坏(并且服务帐户被盗)，则该服务帐户不会被过度授予，并且您不必更改其他应用程序上的服务帐户 key 。但是，每个项目的服务帐户数上限为 100 个。我没有捕获“每个实例的 key ”。如果您需要轮换 key 或将一把 key 放在保险箱(在您身边)中，您可以生成多把 key 。如果您还有其他想法，请评论!

6. 这要看情况!您的客户端应用程序是否有不同的授权？如果是这样，您必须识别调用者的身份，然后在您的服务内部匹配其授权(我们通常使用 Firestore 执行此操作)。如果简单的身份验证就足够了，则无需执行额外的检查。为什么选择云端点？如果您的 Cloud Run 处于私有(private)模式(仅接受 Google 签名的 JWT)，并且您的客户端应用程序只能使用 API KEY，则您需要一个中介来验证客户端应用程序并在转发请求时生成 JWT

7. 如前所述，Google 仅执行身份验证。对于您自己的应用程序，您必须自己管理授权。是的，如果您接受第 3 方 OIDC 提供商(Google、Facebook、LinkedIn，就像您可以使用 Firebase Auth(或 Cloud Identity Platform)一样，您可以向所有有效身份验证开放您的 API)

8. 在这种情况下，Google ID 用于(调用方)身份验证，API KEY 用于(项目)身份验证。首先，API key 标识 GCP 项目，而不是帐户(用户或服务)或应用程序。只是一个项目! (这意味着如果您想严格识别不同的应用程序(因为每个应用程序有不同的授权)，则每个应用程序需要一个 GCP 项目，每个项目需要一个 API key ，并且您无法自动生成 API key ，因此您需要手动执行此操作，...无聊的时刻...)。其次，在这种情况下，您可以使用 API key 来实现配额和速率限制功能(实际上，为此您需要 API key ，而不是 Google ID，它仅适用于 API key )

9. 与之前相同

10. 如果您指的是具有经过身份验证的用户的浏览器，请使用 Firebase Auth(或 Cloud Identity Platform)对您的用户进行身份验证，仅此而已。

信息量很大，可能不清楚或顺序错误。如果你愿意的话，我写了 2 篇文章，其中 authentication with API Keys ，第二个为 the Quotas/rate limit .

我只有谈论这个主题的法语视频。但我会present it in english to the Serverless Day Zurich later in September ，我将尝试更清楚地解释 API key 的概念以及何时使用它们!