GCP 通过 Compute Engine 的服务帐户访问和存储密码/凭据的正确方法

Question

“不要在源代码中嵌入与身份验证相关的秘密” - one may hear frequently。好的，所以我使用Key Management Service 和Secret Manager。

但是，如何从 Compute Engine 的虚拟机和本地开发环境中正确访问存储在其中的机密？

我可以想到任何一个：

1. 使用 default Service Account credentials 访问机密，但是我如何在本地开发环境和本地 Docker 容器内部（即，计算引擎外部）访问机密？

   李>

2. 使用custom Service Account 访问机密，但是我需要将其 JSON 密钥存储在某处并从我的代码中访问它。为此，我有两个选择：

   2.1。将其与源代码一起存储，因此我将其保存在开发机器和 Docker 容器中。但这违背了开场白“不要在源代码中嵌入秘密......”。坏主意。

   2.2。将它存储在我的开发机器上的某个地方。但是我的 Docker 容器如何访问它呢？我可以将密钥作为 Docker 机密提供，但那不会又是 “嵌入源代码” 吗？在我的虚拟机上启动容器后，我需要从某个地方提供该秘密，再次回到秘密如何首先到达虚拟机的问题。

我知道Application Default Credentials (ADC) 可以尝试使用选项 2，然后回退到选项 1 - 但是，我该如何解决选项 2 的冲突？服务帐户凭据应该驻留在哪里才能在我的本地开发人员和本地容器中访问 - 而不是嵌入到源代码中？

Answer 1

我找到了一种方法来完成这项工作，(sortof)：

• 在本地开发环境中，依赖 GOOGLE_APPLICATION_CREDENTIALS 指向从 GCP 手动下载的服务帐户凭据。

• 在本地 Docker 容器上，提供相同的文件作为机密。如果未设置 GOOGLE_APPLICATION_CREDENTIALS，我的应用会搜索 /run/secrets/。

• 在 Compute Engine 虚拟机上，从 Google 存储桶（之前已上传）下载该文件。 Given that the default Service Account is used 如果没有指定其他凭据，我可以从存储桶中 gutils cp 那个文件。然后将下载的文件作为机密提供给容器。

不过，我仍然不确定从不嵌入源代码的角度来看这是否好。从存储桶中上传和下载凭据也感觉非常手动。任何有关如何改进此身份验证的提示都非常受欢迎。

Answer 2

您的云存储创意很好，可以解决您的需求；从 VM 实例访问存储在 Secret Manager 上的秘密的最简单方法是通过 curl、gcloud 命令或 "accessing a secret version" 的 python 脚本，然后将它们作为临时变量存储在要使用的代码中。要使用的服务帐户可以是 CE 默认服务帐户，请记住它必须具有 secretmanager.secretAccessor 和/或 secretmanager.admin 角色才能从 SM 中获取它们。另外确保 VM 实例具有所有 GCP 资源或至少安全 API 的正确 API 范围。