我已阅读以下教程:Vault Configuration
确定,我们安装了Vault服务器,并放置了2对秘密属性:
$ vault kv put secret/gs-vault-config example.username=demouser example.password=demopassword
$ vault kv put secret/gs-vault-config/cloud example.username=clouduser example.password=cloudpassword
Spring Boot应用程序具有以下属性(bootstrap.properties
):
spring.application.name=gs-vault-config
spring.cloud.vault.token=00000000-0000-0000-0000-000000000000
spring.cloud.vault.scheme=http
spring.cloud.vault.kv.enabled=true
因此基于spring.cloud.vault.token
应用程序能够读取安全属性(名称和密码),但spring.cloud.vault.token
存储在不安全的位置-bootstrap.properties
存储在代码存储库中。您能否解释一下为什么安全?
我们发现这是不安全的。如何使其安全?我了解可能有几种解决方案可以确保它的安全性,但是对我来说,一个简单的示例就足够了。
您能解释一下为什么安全吗?
答案是,这样做不安全...如果这样做的话。例如,Spring Vault reference manual说:
“请仔细考虑您的安全要求。如果您想快速开始使用Vault,可以使用静态令牌身份验证,但是静态令牌不会受到任何进一步的保护。向非预期方的任何公开都允许Vault与关联的令牌角色一起使用。”
您应该保护您的静态令牌,或者只授予它们访问您很高兴为人们所熟知的文件库中“秘密”的权限。
或者,让您的应用程序使用authenticated method生成短期动态令牌。
据我了解,最初的问题很难将密码存储在Github上的application.properties文件中。
并且将静态Vault令牌存储在Github上的application.properties文件中同样糟糕。
有什么区别?
几乎没有区别1。这只是使用保险柜的错误方法。
1-有一个小优点,如果您发现令牌意外泄漏,则可以使令牌无效。但这并不意味着故意发布它是明智的。
那么,您如何安全地处理事情?
首先,您必须保护将使用机密的计算机。即使您不打算将实际的机密存储在磁盘上,您也需要在每个计算机上(安全地)存储一个不同的机密,以便它们可以向保存真实机密的位置进行身份验证。
这里是使用Chef的示例。
设置一个安全的Chef服务器,该服务器保存您计算机的配置;即所有需要安装的东西的食谱,说明要应用的食谱的节点描述等。
当您将计算机作为节点引导时,将为该计算机生成密钥对,并在Chef服务器中注册。密钥对也保存在计算机上,必须牢固保存。
然后您使用Chef客户端运行安装和配置服务器的配方。
请注意,这依赖于具有适当安全性的系统来运行Chef服务器。它还依赖于每个节点的足够安全性来保护自己的密钥。
还有其他方法,但是如果您不能充分保护主机,则将无法进行任何操作。