"不要在源代码中嵌入与身份验证相关的秘密">-人们可能经常听到。好的，所以我使用密钥管理服务和密钥管理器。
但是，如何从计算引擎的VM和本地开发环境中正确访问存储在那里的机密
我可以想到任何一个：
-
使用默认的服务帐户凭据访问机密，但我如何在本地开发环境和本地Docker容器内部(即计算引擎外部(访问机密？
-
使用自定义服务帐户访问机密，但随后我需要将其JSON密钥存储在某个位置，并从代码中访问它。为此，我有两个选择：
2.1.把它和源代码一起存储，所以我把它放在开发机器和Docker容器中。但这违背了开场白"不要在源代码中嵌入秘密…">。坏主意。
2.2.将其存储在我的开发机器上的某个位置。但是我的Docker容器是如何访问它的呢？我可以将密钥作为Docker机密提供，但这不是再次"嵌入源代码">吗？在我的虚拟机上启动容器后，我需要从某个地方提供这个秘密，再次回到秘密最初是如何到达虚拟机的问题。
我知道应用程序默认凭据(ADC(可以尝试使用选项2，然后回退到选项1-但是，如何解决选项2的冲突？服务帐户凭据应该位于哪里，以便在我的本地dev和本地容器中都可以访问，而不是嵌入在源代码中的？
我找到了一种方法来实现这一点，(sorto(：
-
在本地dev-env上，依靠
GOOGLE_APPLICATION_CREDENTIALS指向从GCP手动下载的服务帐户凭据。 -
在本地Docker容器上，提供相同的文件作为机密。如果未设置
GOOGLE_APPLICATION_CREDENTIALS，我的应用程序将在/run/secrets/中搜索它。 -
在计算引擎虚拟机上，从谷歌存储桶下载该文件(之前已上传(。假设在没有指定其他凭据的情况下使用默认的服务帐户，我可以从bucket中
gutils cp该文件。然后将下载的文件作为机密提供给容器。
尽管如此，我仍然不确定从不嵌入源代码的角度来看这是否好。从bucket上传和下载凭据也让人感觉很手动。任何关于如何改进此身份验证的提示都非常受欢迎。
您的云存储理念很好，可以解决您的需求；从VM实例访问存储在Secret Manager上的机密的最简单方法是通过curl、gcloud命令或python脚本，通过"访问机密版本"，然后将它们作为临时变量存储在要使用的代码中。要使用的服务帐户可以是CE默认服务帐户。请记住，它必须具有secretmanager.secretAccessor和/或secretmanager.admin角色，才能从SM获取它们。此外，请确保VM实例具有所有GCP资源的正确API作用域，或至少具有API的安全作用域。