Security 使用kubernetes用敏感信息填充Docker容器

我有一个pod，它运行需要访问敏感信息（如API密钥和DB密码）的容器。现在，这些敏感值嵌入控制器定义中，如下所示：

env:
- name: DB_PASSWORD
  value: password

然后可在Docker容器中作为环境变量

$DB\u PASSWORD

使用。一切都相当容易

但在阅读他们的文档时，他们明确表示，将敏感配置值放入定义中违反了最佳实践，并且可能是一个安全问题。我能想到的唯一其他策略是：

• 为每个用户社区或命名空间创建OpenPGP密钥
• 用于将配置值设置为etcd（使用私钥加密）
• 创建包含私钥的kubernetes秘密
• 将该秘密与容器关联（意味着私钥可以作为卷装载进行访问）
• 当容器启动时，它将访问卷装载中的文件以获取私钥，并使用它来解密从etcd返回的conf值
• 然后可以将其合并到中，后者根据模板定义填充本地文件（如Apache或WordPress配置文件）

这看起来相当复杂，但更安全、更灵活，因为这些值将不再是静态的并以明文形式存储

所以我的问题，我知道这不是一个完全客观的问题，是这是否完全必要？首先，只有管理员才能查看和执行RC定义；因此，如果有人违反了库伯内特斯大师的规定，你还有其他问题要担心。我看到的唯一好处是，不会有秘密以明文形式提交到文件系统的危险

---

有没有其他方法可以安全地用机密信息填充Docker容器？

除非你有很多兆字节的配置，否则这个系统听起来不必要的复杂。预期用途是将每个配置放入一个秘密中，需要该配置的pod可以将该秘密装载为一个卷

然后，您可以使用各种机制中的任何一种将该配置传递给任务，例如，如果它是环境变量

source secret/config.sh/mybinary

是一种简单的方法

---

我认为将私钥存储为机密不会获得任何额外的安全性。

我个人会决定使用远程密钥管理器，您的软件可以通过HTTPS连接通过网络访问。例如，或可能符合要求

我将把keymanager托管在一个单独的隔离子网上，并将防火墙配置为只允许访问我希望需要密钥的ip地址。KeyWhiz和Vault都有一个ACL机制，所以你根本不必对防火墙做任何事情，但是不必考虑它——但是这里的关键是在单独的网络上托管密钥管理器，甚至可能是单独的托管提供者。

---

容器中的本地配置文件只包含密钥服务的URL，还有一种可能是从keymanager中检索密钥的凭据——如果攻击者与ACL/IP地址不匹配，那么这些凭据对他来说将是无用的。

@larsks但机密的定义文件不会以明文形式存储凭据吗？或者在base64中，可以很容易地解码。是的，我误解了你已经在利用那个API的事实。所以，没关系……据我所知，秘密是传递敏感信息的方式，但它有其局限性。但这比直接在ENV variables.Re中传递敏感信息要好。“其他方式”：好吧，这就是为什么我不确定这是个好主意的原因：1。我认为在单个文件中放置机密有点笨拙，因为这不是大多数应用程序处理敏感数据的方式。您需要编写额外的启动逻辑，这很不方便。2.装载卷文件并将其放入env太静态。我宁愿将我的应用程序配置动态存储在etcd中，使用

crypt

进行加密。3.从安全角度来看，我认为需要额外的时间和知识来访问比以明文形式给他们要好。一个秘密只能有256个字符长。。。所以可能对密码和密钥很有效，但对证书之类的东西不起作用。。。这可能要长得多。一个密钥只能有256个字符；秘密数据没有限制，因此hohner的观点是：1：不管发生什么，你都必须编写启动逻辑。2：如果你可以在不重启应用程序的情况下更改配置，那么是的，你可能想自己管理它；这不是正常情况。3：你总是直接以明文形式给出一些东西，不管是密钥还是数据本身。