使用 OAuth2 令牌来交互使用 GCP 服务而不是服务帐户（密钥）

Question

为了限制要管理的服务帐户的数量以及处理它们的密钥，我正在探索从开发人员笔记本电脑或台式机访问 GCP 资源的其他方法，以便我可以运行临时脚本或交互式程序（例如访问 GCP 服务的 Jupyter notebook）。

使用gcloud auth application-default login 在通过网络浏览器进行身份验证后生成一个刷新令牌，该令牌可用于获取和更新可用于与 GCP 服务交互的访问令牌。

我遵循的工作流程是这样的：

1. 运行gcloud auth application-default login。这会在我的磁盘上生成一个 JSON 文件 包含刷新令牌。
2. 将 JSON 文件位置导出为 GOOGLE_APPLICATION_CREDENTIALS 环境变量 GOOGLE_APPLICATION_CREDENTIALS=/Users/my.username/.config/gcloud/application_default_credentials.json 
3. 使用该文件通过 Google 身份验证库进行身份验证并与不同的 GCP 服务进行交互。

这很方便，因为它减少了在团队成员之间传播、保护以及在需要时共享服务帐户密钥文件的需要。但是，我注意到提供的刷新令牌不会过期并且仍然有效。

除非我在这里遗漏了什么，否则这会使application_default_credentials.json 文件与服务帐户密钥一样敏感。如果它丢失或受到损害，它可以用于获取访问令牌而无需重新验证，这是相当不安全的，IMO。

我们知道 GCP 安全最佳做法建议将服务帐号（及其密钥）用于服务到服务工作负载。我正在描述的这个场景是针对临时代码的开发/测试 开发人员或工程师的笔记本电脑。我们认为，与使用存储在硬盘中的长期服务帐户密钥相比，强制用户每隔几个小时通过网络进行交互式身份验证以获取新令牌会更加安全和方便。

我已通读 [1]，但找不到明确的答案。

• 有谁知道这些刷新令牌是否过期？
• 有没有办法控制和限制它们的生命周期（最好是几小时或几分钟）？
• 此方案的最佳/常见做法是什么？每个用户使用一个服务帐号（和密钥）？

[1]https://developers.google.com/identity/protocols/OAuth2#expiration

Answer 1

注意：用户凭据也有刷新令牌。

有谁知道这些刷新令牌是否过期？

Google OAuth 刷新令牌不会过期。它们可以被撤销。

有没有办法控制和限制它们的寿命（理想情况下 小时还是分钟）？

您可以定期撤销刷新令牌，这将使访问和客户端 ID 令牌无效。这意味着您正在处理刷新令牌，这增加了另一个需要管理的安全问题。

这种情况的最佳/常见做法是什么？使用单个 每个用户的服务帐户（和密钥）？

如果您使用用户凭据（您登录 Google 的方法），您将收到 SDK 警告，并且如果您进行大量 API 调用，您将被阻止。 Google 不希望您使用用户凭据代替服务帐户凭据。用户凭据的验证过程需要在 Google 的后端系统上付出更多努力。假定用户凭据是在不安全的环境（网络浏览器）中创建的，而服务帐户凭据则假定是在安全的环境中创建的。

最佳做法是将服务帐号 JSON 密钥文件颁发给仅具有该应用运行所需权限的单个应用。例如，如果您创建一个只需要读取 Cloud Storage 对象的工具，请创建一个仅具有读取权限的服务帐号。应定期轮换服务帐户密钥并下载新密钥并删除旧密钥。每个应用程序都应该有自己的服务帐户 JSON 密钥文件。我写了一篇关于如何在 Cloud Storage 上安全地存储 JSON 密钥文件的文章。这有助于旋转密钥，因为您的应用程序只是在需要时下载最新的密钥。 (link)。我的文章讨论了 Google Cloud Run，但也适用相同的原则。