HashiCorp Vault将填充kubernetes的秘密

Question

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

我的问题是，HashiCorp Vault是否也习惯于用凭证填充库伯内特斯秘密，以及如何实现这一点？

Answer 1

正如@Rico提到的那样，无论是在Vault还是在Kubernetes，都暴露了秘密，这首先挫败了使用Vault的目的。

使用Vault，数据是加密的(传输/rest)，您可以提供对谁可以访问什么数据的访问粒度控制。将Vault内部的数据公开给Kubernetes秘密对象(基本上仅限于base64编码)，将在很大程度上击败Vault的最大优点，即保护您的基础设施，并作为负责管理您的秘密的唯一实体。

金库是一个很棒的工具，但在我看来，对于非开发配置，它可能会变得相当复杂，因为您将不得不附加领事这样的组件，这样您就可以拥有一个持久的后端存储，因此，使用像sidecar模式这样的体系结构分布式模式可能也是非常过分的，根本不推荐使用。

• 但是有了它，您可以在与“主”容器相同的Pod中拥有一个保险库实例，因此可以利用Vault提供的加密服务，但是我们将把vault的生命周期与Pod的生命周期结合起来。
• 使用这种方法，我们需要在每个Pod上都有一个Vault实例，以防我们不得不访问秘密信息，这只会使系统变得非常复杂。通过这种方法，我们可以在多个保险库实例中分离每个对象所需的秘密信息，从而将基础设施的秘密信息传播到多个地方，但我们继续增加管理基础设施的挑战。

因此，我绝对明白，想办法把一个Pod的秘密信息放在它旁边似乎很诱人，特别是以一种简单的方式，但如果它完全不加密的话，它肯定会达到目的。

既然这样，为什么不简单地创建一个Vault控制器，它将是负责与Vault交互的实体，它将负责查询Vault中的包装令牌，在Pod中的init容器打开后，它可以临时提供对某些秘密信息的访问权。这是由于启动Pod所需的额外时间，因为我们需要执行一些早期调用才能检索包装的令牌？或者ut是由于在需要从Vault查询机密数据时必须执行额外调用的额外延迟吗？

每当我想到集成库伯内特斯和Vault的想法时，我通常都会想到凯尔西·海托尔解释说的这里创建的以下原型。

Answer 2

我的问题是，HashiCorp Vault是否也可以用凭证填充库伯内特斯秘密，这是如何实现的？

是也不是。

不:无论是库伯内特斯还是跳马队都没有任何支持。只支持使用服务帐户与Vault进行身份验证。一个更大的问题是，为什么你想让伏特在库伯奈特的秘密中填充秘密，因为它们已经是“安全的”了。

是的:你必须建立你自己的自动化。你所有的秘密都是这样的：

kubectl create secret generic mynicepass2 --from-literal=key1=`vault read <your-secret>`

Answer 3

考虑到3年过去了，一些新的东西：

这在BanzaiCloud的变异网钩中是可能的，特别是要注意BanzaiCloud的变异网钩。

可以肯定的是，您需要考虑Andre提到的一些事情:最终您将得到库伯奈特的秘密数据(而不是将秘密数据注入POD)。

还有保险库CSI供应商