使用秘密管理器的附加价值
我有一个相当标准的应用程序写在Java它也运行查询对数据库。应用程序位于GCP上，数据库位于Atlas上。
出于可以理解的原因，我不想在代码中保留数据库的用户名和密码。
所以我想到的选项1是将用户名和密码作为环境变量传递给GCP中的应用程序容器。
选项2是在GCP中使用秘密管理器，并将我的用户名和密码存储在那里，并将GCP凭据作为环境变量传递给GCP中的应用程序容器。
我的问题是，如果2号选项有附加值，它的附加值是多少？从安全角度来看，选项2似乎更糟糕，因为如果某个黑客获得了谷歌的证书，它就可以访问存储在Secret Manager中的所有机密。
我不知道在这种情况下，最佳做法是什么，建议做什么。谢谢你的帮助。
共有3个答案
要在谷歌云上使用Secret Manager，您需要安装Secret Manager Java SDK库。本文档展示了如何开始使用Secret Manager API的云客户机库，您只需要转到Java部分。此库帮助您访问密钥，以便应用程序使用。
下面的链接显示了如何通过查看机密的元数据来获取有关机密的详细信息。请记住，查看机密的元数据需要机密、项目、文件夹或组织上的机密查看器角色（角色/secretmanager.Viewer）。
我建议你创建一个特殊的服务帐户来处理你的应用程序的适当权限，因为如果你没有定义SA，默认SA将生成请求，而且它不安全。您可以在此链接中了解有关如何创建服务帐户的更多信息
另一方面，您可以找到如何使用以下指南的示例，该指南包含自动查找凭据的一个很好的示例，这比手动传递凭据更方便、更安全。
如果您的应用程序驻留在GCP中，则不需要服务号密钥文件（这是您的安全问题，您是对的。我就此写了一篇文章）
TL；DR使用ADC（应用程序默认凭据）自动获取谷歌云组件上自动提供的服务帐户凭据（有关更多详细信息，请查看元数据服务器）。
然后授予此组件标识（默认情况下或支持时由用户定义），即服务号电子邮件，以访问您的机密。
就这些！您的代码和环境变量中没有秘密，登录/密码和服务帐户密钥文件中也没有秘密。
如果在Java中使用ADC有困难，请毫不犹豫地分享您的代码。我将能够帮助你们实现这一目标。
在GCP秘密管理器中拥有凭据将帮助您跟踪集中位置中的所有秘密和更改，并从任何应用程序进行全局访问。
对于一个标准应用程序，一个JAVA连接到一个DB，可能不会增加太多值。
因此，你可以研究库伯内特的秘密。
-
我们在AWS环境中部署了完整的应用程序，我们发现AWS秘密管理器是存储数据库和其他一些组件的秘密的正确选择。
-
我正在尝试从使用文件，以使用谷歌云平台机密管理器。我已经按照这里的说明操作了，但是我遇到了一个错误，说我没有权限访问这个秘密。 这就是我得到的错误： 我确实创建了一个具有“所有者”权限的服务帐户，下载了它，并使其
-
我创造了一个“其他类型的秘密”。我还在这个模板中添加了一个作为give的lambda函数。现在，当我试图立即旋转时，它会说“Fail to Rotion the secret”test_secret_Rothing“以前的旋转没有完成。将重新尝试该旋转。”轮转的时间是一天，即使第二天我看到分泌物也没有更新。我只是添加了那个lambda函数。我需要定义任何参数或任何其他lambda设置吗。我还在文档
-
我有一个秘密存储在使用Terraform模块部署的AWS秘密管理器中，该模块支持秘密循环。我没有访问那个模块的源代码，所以我不能修改它。我想使用Terraform禁用秘密旋转。我应该使用哪种资源？需要如下所示的所有3个参数，并且没有任何参数来禁用循环。属性接受1到365之间的值，因此传递0也不是一个选项。
-
null 例如，轮转设定为7天。所以我在我的应用程序中编码每7天刷新一次...不好，因为很难精确计时。 另一种方法是，如果我的应用程序面临身份验证异常，只需刷新密码，建立一个新的连接，并重试应用程序逻辑。 行业标准是什么？
-
我有一个使用Bosh部署的concourse环境。它配置有AWS机密管理器。管道机密模板的格式为 我在AWS秘密管理器（其他类型的秘密）中创建了一个秘密，其值如下。 我在团队中设置了一个总汇管道。