kubernetes - HashiCorp Vault 用于填充 kubernetes secret

最近我了解了 HashiCorp Vault 及其与 Kubernetes 结合的用法。我发现了两篇非常棒的博客文章，内容是关于如何使用 HashiCorp Vault 通过使用 init-container 和共享卷( post1 、 post2 )动态生成凭证。 Kubernetes 还提供了一种使用 Kubernetes secret 处理凭据的好方法，这也使人们能够通过环境变量读取凭据。因此，它为 secret 存储提供了一个很好的抽象。

我的问题是 HashiCorp Vault 是否也可以用于 使用凭证 填充 Kubernetes Secrets 以及如何实现？

最佳答案

正如@Rico 提到的，暴露 Vault 和 Kubernetes 中的 secret 首先违背了使用 Vault 的目的。

使用 Vault，数据被加密(传输/休息)，您可以提供对谁可以访问哪些数据的访问粒度控制。将 Vault 中的数据暴露给 Kubernetes Secret 对象，该对象基本上仅限于 base64 编码，这将在很大程度上破坏 Vault 的最大好处，即保护您的基础设施并成为负责管理您的 secret 的单一实体。

Vault 是一个很棒的工具，但在我看来，对于非开发配置，它可能会变得更加复杂，因为您将不得不附加 Consul 之类的东西，以便您可以拥有持久的后端存储，因此使用架构分布式模式，例如因为 sidecar pattern 也可能非常矫枉过正，根本不推荐。

但是有了它，您可以在与“主”容器相同的 Pod 中拥有一个 Vault 实例，因此可以利用 Vault 提供的加密服务，但我们会将 Vault 的生命周期与 Pod 的生命周期联系起来。

使用这种方法，我们需要在每个 Pod 上都有一个 Vault 实例，以防我们计划访问 secret 信息，这只会使系统变得更加复杂。
通过这种方法，我们可以将多个保管库实例上的每个对象所需的 secret 信息分开，从而将基础设施的 secret 信息传播到多个地方，但我们不断增加管理基础设施的挑战。

所以我绝对明白，试图找到一种方法来将 Pod 所需的 secret 信息放在它旁边可能看起来很诱人，特别是以简单的方式，但如果它只是完全未加密，它肯定会失败。

考虑到这一点，为什么不简单地创建一个 Vault Controller ，它是负责与 Vault 交互的实体，并且将负责向 Vault 查询包装 token ，它可以临时访问某些 secret 信息，之后由 Pod 内的 init 容器解开？这是因为启动 Pod 需要额外的时间，因为我们需要执行一些早期调用以检索 Wrapped Token？或者是因为在需要从 Vault 查询 secret 数据时必须执行额外调用的额外延迟？

每当我想到集成 Kubernetes 和 Vault 的想法时，我通常会想到以下由 Kelsey Hightower 创建的原型(prototype) here 。

关于kubernetes - HashiCorp Vault 用于填充 kubernetes secret ，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/52859115/