我正在尝试了解 Spring Vault 中身份验证令牌背后的概念以及部署链的外观？
在我阅读的任何地方，我都看到必须以某种方式静态提供身份验证令牌，但我不明白这是如何保护的？如果我使用保险库来安全地存储我的秘密，而不仅仅是存放在属性文件中，那么为什么要将令牌保存在一个文件中？
当我刚开始阅读有关 Vault 的信息时，我期待一个“人机交互”阶段，其中令牌作为系统参数或在应用程序部署/启动之前的最后一刻提供。
此外，我看不出 Vault 如何适应全自动部署链。每当我的主分支发生更改时，我的 Jenkins 都会自动构建，并将发布 jar 并通过 ssh 将其运行到指定的机器上。根据我对 Vault 的理解，这不是我发布应用程序的方式，对吗？
【问题讨论】：
标签： security authentication spring-boot jenkins hashicorp-vault
您的帖子包含多个主要与信任有关的问题。
如果 Token 是静态保存的，Spring Vault 的意义何在？
身份验证机制至少取决于：
对于某些环境，带有静态令牌的 Vault 非常好，而其他情况则需要多因素身份验证。使用静态令牌，您可以在所有应用程序/应用程序实例中使用单个令牌，或在每个应用程序/应用程序实例中使用不同的令牌。这样您就可以锁定一个特定的令牌，而其他令牌仍然有效。
也许从不同的角度看待这个问题会有所帮助：您试图通过 Vault 解决什么要求？您愿意在安全引入问题上花费多少精力？
Vault 使用令牌作为一般身份验证机制，但不限于此。您可以使用客户端证书、多重身份验证和其他一些机制来获取会话令牌，然后将其保存在内存中。
如何保护身份验证令牌？
这取决于您的环境和您愿意承担的风险。您可以至少通过以下方式向任何 Java 应用程序提供静态令牌，一般来说，配置属性：
每种可能性都有其自身的属性和实现的努力。如果您的运行时/容器有足够的（这是您定义的级别）保护，那么属性文件就可以了。如果您的要求是提高安全门槛，您可能希望在应用启动期间输入令牌并提示。
我看不出 Vault 如何适应全自动部署链。
这不完全是一个问题，但可能是您帖子中最有趣的一句话。
当您今天使用 Jenkins 和 SSH 进行部署时，这意味着您信任 Jenkins 机器和实际执行部署的操作员。在这种安排下，信任 Jenkins 似乎是可以接受的风险，因为对运行时的身份验证是 Jenkins 设置的一部分。从这里产生的问题是：你相信你的运行时吗？您信任它到哪个级别？如果您不信任您的运行时（即运行时环境泄露秘密，并且非预期方可以轻松访问它），那么您可能会遇到比静态令牌更大的问题。
【讨论】：