最近我了解了HashiCorp Vault及其与Kubernetes结合使用的情况。我找到了两篇非常棒的博客文章，介绍如何使用 HashiCorp Vault 通过使用 init-container 和共享卷(post1、post2(即时生成信条。Kubernetes 还提供了一种使用 Kubernetes 机密处理凭据的好方法，这也使人们能够通过环境变量读取凭据。因此，它为机密存储提供了一个很好的抽象。
我的问题是，HashiCorp Vault 是否也可以用于用凭据填充 Kubernetes Secrets，以及如何实现？
正如@Rico提到的，暴露 Vault 和 Kubernetes 中的秘密首先违背了使用 Vault 的目的。
借助保险柜，数据经过加密(传输/静态(，您可以对谁可以访问哪些数据进行访问权限粒度控制。将 Vault 中的数据暴露给基本上仅限于 base64 编码的 Kubernetes Secret 对象，将在很大程度上破坏Vault的最大好处，即保护您的基础设施并成为负责管理您的机密的单一实体。
Vault 是一个很棒的工具，但在我看来，对于非开发配置来说，它可能会变得更加复杂，因为您将不得不附加 Consul 之类的东西，以便您可以拥有一个持久的后端存储，因此使用架构分布式模式(例如 sidecar 模式(也可能是非常矫枉过正的，根本不推荐。
- 但是有了它，您可以将一个 vault 实例与"主"容器"活"在同一个 Pod 中，从而利用 Vault 提供的加密服务，但我们会将 Vault 的生命周期与 Pod 的生命周期联系起来。
- 使用这种方法，我们需要在每个 Pod 上都有一个 Vault 实例，以防我们计划必须访问秘密信息，这只会使系统变得更加复杂。 通过这种方法，我们可以分离多个保管库实例上每个对象所需的机密信息，从而将基础架构的机密信息传播到多个位置，但我们不断增加管理基础架构的挑战。
所以我绝对理解，试图找到一种方法将 Pod 所需的秘密信息放在它旁边似乎很诱人，尤其是以一种简单的方式，但如果它完全未加密，它肯定会破坏目的。
有了这个，为什么不简单地创建一个 Vault 控制器，该控制器将是负责与 Vault 交互的实体，并且负责向 Vault 查询包装的令牌，在被 Pod 内的 init 容器解开包装后，它可以暂时访问某些秘密信息？这是由于启动 Pod 需要额外的时间，因为我们需要执行一些早期调用才能检索包装的令牌吗？还是由于在需要从 Vault 查询机密数据时必须执行额外调用的额外延迟？
每当我想到集成 Kubernetes 和 Vault 的想法时，我通常会想到以下由 Kelsey Hightower 创建的原型。
我的问题是，HashiCorp Vault 是否也可以用于用凭据填充 Kubernetes Secrets，以及如何实现？
是和不是。
否：Kubernetes 或 Vault 方面都没有支持。仅支持使用服务帐号向保险柜进行身份验证。一个更大的问题是，为什么你希望 Vault 在 Kubernetes 机密中填充机密，因为它们在 Vault 中已经是"安全的"。
是的：您必须构建自己的自动化。对于你所有的秘密来说，都是这样的东西：
kubectl create secret generic mynicepass2 --from-literal=key1=`vault read <your-secret>`
一些新的东西，考虑到5年过去了：
当然，你需要考虑Andre提到的事情：你最终会得到带有该秘密数据的Kubernetes秘密(而不是将秘密数据注入POD(
-
保险库 CSI 提供商
-
保管库机密运算符。在 Vault 1.13 中引入，自 2023 年 4 月起处于测试阶段。
在比较 HashiCorp 支持的 HashiCorp Vault 和 Kubernetes 集成的三种方法时，提供了 vault-agent sidecar、CSI 提供程序和 Vault Secrets Operator 之间的比较。
-
HashiCorp Vault 作为提供者的外部机密。如果您同时使用不同的机密提供程序，则可能特别相关
-
万岁云的变异网钩