"不要在源代码中嵌入与认证有关的秘密" - 时有所闻. 好吧，所以我用 钥匙管理服务 和 秘密经理.
但后来, 我如何正确地从Compute Engine的虚拟机和我的本地开发环境访问存储在那里的秘密？
我可以想到两种方法。
使用 默认服务账户凭证但我如何在本地开发环境和本地Docker容器内部（即在计算引擎之外）访问秘密？
访问秘密的方法是使用 自定义服务账户但我需要把它的JSON键存储在某个地方，然后从我的代码中访问它。为此，我有两个选择。
2.1. 把它和源代码一起存储，所以我把它放在开发机和Docker容器中。但这就违背了开头的声明 "不要在源代码中嵌入秘密.". 馊主意。
2.2. 把它存储在我的开发机器上的某个地方。但是我的Docker容器如何访问它呢？我可以提供密钥作为Docker的秘密，但那岂不是又是一次的 "嵌入源代码"? 在我的虚拟机上启动容器后，我需要从某个地方提供那个秘密，然而又回到了秘密首先是如何到达虚拟机的问题。
我知道 应用程序默认凭证 (ADC)可以尝试使用选项 2，然后回退到选项 1 - 然而，我如何解决选项 2 的冲突？服务账户凭证应该放在哪里，才能在我的本地开发和本地容器中都可以访问--而不是在我的本地容器中。嵌入源码?
我发现了一个方法来使这个工作，(算是):
在本地开发环境下，依靠 GOOGLE_APPLICATION_CREDENTIALS 来指向从GCP手动下载的服务账户凭证。
在本地Docker容器上，提供相同的文件作为秘密。然后，我的应用程序搜索 /run/secrets/ 为它 GOOGLE_APPLICATION_CREDENTIALS 未设置。
在 Compute Engine 虚拟机上，从 Google 存储桶中下载该文件（之前已上传）。鉴于使用的是默认的服务账户 如果没有指定其他凭证，我能够 gutils cp 该文件从一个桶中下载。然后把那个下载的文件作为秘密提供给容器。
不过，我还是不知道这样做是否是好的，因为从 没有嵌入到源代码中. 从桶里上传下载凭证，感觉也很手动。任何关于如何改进这种认证的提示都非常欢迎。
你的云存储的想法是好的，可以满足你的需求；从虚拟机实例访问存储在Secret Manager上的秘密的最简单的方法是通过curl、gcloud命令或python脚本来访问。"访问一个秘密版本" 然后把它们作为一个短暂的变量存储在要使用的代码中。要使用的服务账户可以是CE默认的服务账户，只是要记住它必须有secretmanager.secretAccessor和or secretmanager.admin角色才能从SM中抓取它们。额外确保虚拟机实例对所有GCP资源有正确的API作用域，或者至少是安全API的作用域。