HashiCorpVault填充kubernetes秘密

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

我的问题是，还可以使用HashiCorp Vault 填充凭据来填充Kubernetes Secrets，如何实现？

正如@Rico提到的那样，在Vault和Kubernetes中公开秘密都不利于首先使用Vault的目的。

使用Vault，数据被加密（传输/剩余），并且您可以提供访问权限控制，以控制谁可以访问哪些数据。里面保管库中的数据暴露在它基本上仅限于base64编码一个Kubernetes秘密对象，将在很大程度上战胜的最大的好处库，这是确保您的基础架构，并负责管理你的秘密的单一实体。

保管箱是一个很棒的工具，但我认为对于非开发配置，它可能会变得更加复杂，因为您将不得不附加Consul之类的东西，以便拥有持久的后端存储，因此可以利用诸如因为Sidecar模式也可能会造成极大的杀伤力，因此根本不建议使用。

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

使用这种方法，如果我们计划必须访问机密信息，那么我们将需要在每个Pod上都有一个Vault实例，这只会使系统极其复杂。通过这种方法，我们可以在多个保管库实例上分离每个对象所需的秘密信息，因此可以将我们的基础结构的秘密信息传播到多个地方，但是我们不断增加管理基础结构的挑战。

因此，我绝对理解，试图找到一种方法将Pod紧紧放在Pod旁边似乎是很诱人的，特别是以一种简单的方式，但是如果将其完全未加密，肯定会破坏目的。

因此，为什么不简单地创建一个保管箱控制器，该控制器将成为负责与保管箱进行交互的实体，并且将负责向保管箱查询包装的令牌，该控制器可以在被临时保护后临时提供对某些机密信息的访问权限被Pod内部的初始化容器解包了吗？那是由于启动Pod所需的额外时间，因为我们需要执行一些早期调用才能检索包装的令牌吗？还是由于每次需要从Vault查询机密数据时都要执行额外的调用而产生的额外延迟？

每当我想起整合Kubernetes和跳马的想法，我一般倾向于认为有关凯尔西海托创建的原型如下解释这里。