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

GCP correct way to access and store password / credentials through Compute Engine's Service Account

"Do not embed secrets related to authentication in source code" - one may hear frequently. Okay, so I use the Key Management Service and Secret Manager

但是,如何从 Compute Engine 的 VM 和我的本地开发环境正确访问存储在那里的秘密?

我可以想到:

  1. 使用 default Service Account credentials 访问机密,但是我如何在本地开发环境和本地 Docker 容器内部(即在计算引擎)?

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

    2.1。将它与源代码一起存储,所以我将它放在开发机器和 Docker 容器中。但这违背了开场白"Do not embed secrets ... in source code"。坏主意。

    2.2。将它存储在我的开发机器上的某个地方。但是我的 Docker 容器如何访问它呢?我可以提供密钥作为 Docker 秘密,但那不会又是 "embedding in source code" 吗?在我的 VM 上启动容器后,我需要从某个地方提供该秘密,然后再次回到这个秘密最初是如何到达 VM 的问题。

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

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

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

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

  • 在 Compute Engine VM 上,从 Google 存储桶下载该文件(之前已上传)。 Given that the default Service Account is used if no other credential is specified, I'm able to gutils cp 存储桶中的那个文件。然后将该下载的文件作为秘密提供给容器。

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

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