如果令牌静态保存，Spring Vault 的意义何在？

Question

我试图了解 Spring Vault 中身份验证令牌背后的概念以及部署链是什么样子？

在我读过的所有地方，我都看到身份验证令牌必须以某种方式静态提供，但我不明白这是如何保证安全的？如果我使用保险库来安全地存储我的秘密，而不仅仅是放在属性文件中，那么为什么要将令牌保存在其中呢？

当我刚刚开始阅读有关 Vault 的内容时，我期待着一个“人机交互”阶段，其中令牌作为系统参数或在应用程序部署/启动之前的最后一刻提供。

此外，我不明白 Vault 如何适应完全自动化的部署链。每当我的 master 分支发生更改时，我的 Jenkins 都会自动构建，并将发布 jar 并通过 ssh 运行到指定的机器。据我对 Vault 的了解，这不能是我发布应用程序的方式，对吗？

Answer 1

您的帖子包含多个问题，主要与信任有关。

如果Token是静态保存的，Spring Vault还有什么意义呢？

身份验证机制至少取决于：

• 您的安全政策
• 您愿意接受的风险
• 您愿意在运营方面投入的精力。

对于某些环境，具有静态令牌的 Vault 完全没问题，而其他场景则需要多重身份验证。使用静态令牌，您可以在所有应用程序/应用程序实例中使用单个令牌，也可以在每个应用程序/应用程序实例中使用不同的令牌。通过这种方式，您可以锁定特定令牌，而其他令牌仍然有效。

也许从不同的角度看待这个问题会有所帮助：您想用 Vault 满足什么要求？您愿意在安全引入问题上花费多少精力？

Vault 使用令牌作为通用身份验证机制，但并不限于此。您可以使用客户端证书、多重身份验证和一些其他机制来获取会话令牌，然后将其保存在内存中。

身份验证令牌的安全如何？

这取决于您的环境以及您愿意承担的风险。您可以至少通过以下方式向任何 Java 应用程序提供静态令牌（一般来说是配置属性）：

• 属性文件
• 环境变量
• 系统属性
• 命令行参数
• 应用程序启动时提示

每种可能性都有其自己的属性和实现的努力。如果您的运行时/容器具有足够的（这是您定义的级别）保护，则属性文件可能完全没问题。如果您的要求是提高安全标准，您可能需要在应用程序启动期间提示输入令牌。

我不明白 Vault 如何适应完全自动化的部署链。

这不完全是一个问题，但可能是您帖子中最有趣的一句话。

当您今天使用 Jenkins 和 SSH 进行部署时，这意味着您信任 Jenkins 机器和实际执行部署的操作员。在这种安排中，信任 Jenkins 似乎是一个可以接受的风险，因为对运行时的身份验证是 Jenkins 设置的一部分。这里出现的问题是：你相信你的运行时吗？您信任它到什么程度？如果您不信任您的运行时（即运行时环境泄露秘密，非预期方可以轻松访问它），那么您可能会遇到比静态令牌更大的问题。