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

Question

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

env:
- name: DB_PASSWORD
  value: password

然后在Docker容器中作为$DB_PASSWORD环境变量提供。 一切都相当容易。

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

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

这似乎相当复杂，但更安全和灵活，因为值不再是静态的并以明文形式存储。

所以我的问题，我知道这不是一个完全客观的问题，这是否完全是必要的？ 只有管​​理员才能首先查看和执行RC定义; 所以，如果有人违反了kubernetes大师，你还有其他问题需要担心。 我看到的唯一好处是没有明文提交到文件系统的秘密的危险......

有没有其他方法以安全的方式使用秘密信息填充Docker容器？

Answer 1

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

然后，您可以使用各种机制中的任何一种将该配置传递给您的任务，例如，如果它是环境变量source secret/config.sh; ./mybinary source secret/config.sh; ./mybinary是一种简单的方法。

我认为通过将私钥存储为秘密，您不会获得任何额外的安全性。

Answer 2

我个人决定使用远程密钥管理器，您的软件可以通过HTTPS连接通过网络访问。 例如Keywhiz或Vault可能适合该法案。

我会将密钥管理器托管在一个单独的隔离子网上，并将防火墙配置为仅允许访问我希望需要密钥的IP地址。 KeyWhiz和Vault都带有ACL机制，所以你可能根本不需要对防火墙做任何事情，但考虑它并没有什么坏处 - 但是这里的关键是在一个单独的网络上托管密钥管理器，甚至可能一个单独的托管服务商

容器中的本地配置文件将仅包含密钥服务的URL，并且可能是从密钥管理器检索密钥的凭证 - 如果攻击者与ACL / IP地址不匹配，则凭据对于攻击者将是无用的。