我正在尝试理解Spring Vault中身份验证令牌背后的概念以及部署链的外观？
我读到的每个地方，我都看到认证令牌必须静态地提供给我或者其他人，我不明白这是如何保护的？如果我使用保险库安全地存储我的秘密而不只是躺在属性文件中，那么为什么要将令牌保存在一个？
当我刚开始阅读有关Vault时，我期待一个“人工互动”阶段，其中令牌作为系统参数提供，或者在部署/启动应用程序之前的最后一刻提供。
此外，我没有看到Vault如何适应完全自动化的部署链。每当我的主分支被更改时，我的Jenkins会自动构建，并将发布jar并通过ssh将其运行到指定的机器。根据我对Vault的理解，这不是我发布应用程序的方式，这是正确的吗？
答案 0 :(得分：3)
您的帖子包含多个主要涉及信任的问题。
如果令牌被静态保存，Spring Vault的重点是什么？
认证机制至少取决于：
对于某些环境，使用静态令牌的Vault非常精细，而其他场景则需要多因素身份验证。使用静态令牌，您可以在所有应用/应用实例中使用单个令牌，也可以在每个应用/应用实例中使用不同的令牌。这样，您可以锁定特定令牌，而其他令牌仍然有效。
从不同的角度查看问题可能有所帮助：您尝试使用Vault解决了哪些要求？你愿意花多少钱在安全的介绍问题上？
Vault使用令牌作为一般身份验证机制，但并不仅限于此。您可以使用客户端证书，多因素身份验证和一些其他机制来获取会话令牌，然后将其保留在内存中。
如何保护身份验证令牌？
这取决于您的环境以及您愿意承担的风险。您可以通过至少以下方式向任何Java应用程序提供静态令牌（一般来说，配置属性）：
每种可能性都有自己的属性和实施的努力。如果您的运行时/容器具有足够的（您定义的级别）保护，则属性文件可以完全正常。如果您的要求是提高安全条，您可能希望在应用程序启动时输入令牌，并提示。
我不知道保险柜如何适应完全自动化的部署链。
这不是一个问题，但也许是你帖子中最有趣的句子。
当您今天使用Jenkins和SSH进行部署时，这意味着您信任Jenkins计算机和运营商实际执行部署。在这种安排中，信任Jenkins似乎是一个可接受的风险，因为对运行时的身份验证是Jenkins设置的一部分。这里出现的问题是：你相信你的运行时吗？直到你信任哪个级别？如果您不信任您的运行时（即，运行时环境泄露秘密，而非预期的各方可以轻松获得对它的访问权限），那么您可能遇到比静态令牌更大的问题。