使用Google Cloud Endpoints保护Google Cloud上运行的内部API的最佳方法

Question

null

1. 对于我的方案，哪个选项是最合适的？（欢迎其他选择/建议）
2. 选项1通常被认为是安全的吗？如果是这样，为什么还要费心使用云endpoint呢？
3. Google文档提到了不同形式的身份验证（请参见GCP文档中的身份验证方法）。但是，感觉有些是授权（例如API密钥和服务帐户），有些是身份验证（例如Google ID）。这是正确的评估吗？
4. 我假设GCP理解3处理服务帐户，它可以用自己的方式验证它们；没有服务帐户密钥的人无法访问该帐户。
5. 在选项3中：我认为使用多个服务帐户更好，每个应用程序一个，最好每个实例一个密钥。这会被认为是选项3的最佳方式吗？
6. 是否值得在实际API中执行额外的验证？如果是这样，为什么还要有云endpoint？
7. GCP文档没有提到选项4的大问题。我认为这一点应该说得更清楚。
8. 使用选项5有什么好处？我能认出是谁打的电话？那么为什么不制作更多的API键呢？
9. 选项6有用吗？虽然这在云endpoint中被认为是身份验证，但这实际上是授权，对吗？
10. 如果API被web浏览器击中，会发生什么变化？

Answer 1

这里是我的观点（但你的问题是基于观点的，可能会被关闭）

>

看情况而定！！主要是你的客户端应用程序的能力！如果您能够基于一个服务帐户生成一个Google签名的JWT，这是完美的（而不是云endpoint，产品的本地安全性）。请记住，添加一个额外的层意味着一个新的可能的失败点，一个需要维护和更新的新东西。如果你能避免，那就更好了！

是的，看我前面的问题。如果您的客户端应用程序不能生成动态凭据，您可以使用像API密钥这样的静态凭据（具有静态凭据的所有问题，如旋转、窃取、过期等）

看情况！！您的客户端应用程序有不同的授权吗？如果是这样的话，您必须识别调用者的身份，然后在您的服务中内部匹配其授权（我们通常使用Firestore这样做）。如果一个简单的身份验证就足够了，不要执行额外的检查。为什么是云endpoint？如果云在私有模式下运行（只接受Google签名的JWT)，并且客户端应用程序只能使用API密钥，则需要一个中介来验证客户端应用程序，并在转发请求时生成JWT

如前所述，Google只执行身份验证。对于你自己的应用程序，你必须自己管理授权。是的，如果您接受第三方OIDC提供商(Google、Facebook、LinkedIn，就像您可以使用Firebase Auth（或云标识平台）一样，您可以向所有有效身份验证开放您的API）

在本例中，Google ID用于（调用者的）身份验证，API密钥用于（项目的）身份验证。首先，API密钥标识一个GCP项目，而不是一个帐户（用户或服务）或一个应用程序。只有一个项目！（这意味着如果您想严格识别不同的应用程序（因为每个应用程序都有不同的授权），那么每个应用程序都需要一个GCP项目，每个项目都需要一个API密钥，而您不能自动生成API密钥，因此您需要手动完成此操作，...无聊的时刻...)。其次，在这种情况下，您可以使用API密钥来实现配额和速率限制特性（实际上，您需要一个API密钥来实现这个特性，而不是Google ID，它只与API密钥一起工作）

和以前一样

如果您指的是具有经过身份验证的用户的浏览器，请使用Firebase Auth（或云标识平台）对用户进行身份验证，仅此而已。

这是很多信息，也许不清楚或顺序错误。如果您愿意，我写了两篇文章，使用API密钥进行身份验证，第二篇针对配额/速率限制。