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

【问题标题】：Populating Docker containers with sensitive information using kubernetes使用 kubernetes 使用敏感信息填充 Docker 容器
【发布时间】：2015-11-20 17:00:05
【问题描述】：

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

env:
- name: DB_PASSWORD
  value: password

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

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

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

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

所以我的问题，我知道这不是一个完全客观的问题，这是否完全有必要？首先只有管理员才能查看和执行 RC 定义；因此，如果有人破坏了 Kubernetes 主控，您还有其他问题需要担心。我看到的唯一好处是没有秘密以明文形式提交到文件系统的危险......

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

【问题讨论】：

@larsks 但是秘密的定义文件不会以明文形式存储凭据吗？或者在 base64 中，可以很容易地解码。
是的，我误读了您已经在利用该 API 的事实。所以，没关系...
据我了解，Secrets 是传递敏感信息的方式，但它有其局限性。然而，这比直接在 ENV 变量中传递敏感信息要好。
回复。 “其他方式”：stackoverflow.com/questions/30749899/…

标签： security docker kubernetes confd

【解决方案1】：

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

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

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

【讨论】：

嗯，这就是为什么我不确定这是一个好主意的原因： 1. 我认为将秘密放在单个文件中有点笨拙，因为大多数应用程序不是这样处理敏感数据的。您需要编写启动额外逻辑，这很不方便。 2. 挂载卷文件并将它们放在 env 中太静态了。我宁愿将我的应用程序配置动态存储在 etcd 中，使用 crypt 进行加密。 3. 从安全 POV 来看，我认为需要额外的时间和知识才能访问比以明文形式提供给他们更好。
一个 Secret 只能有 256 个字符长...所以可能适用于密码和密钥，但不适用于证书等...可能更长。
秘密 key 只能是 256 个字符；秘密 data 没有限制。
所以对于hohner的观点： 1：无论如何你必须编写启动逻辑。 2：如果您可以在不重新启动应用程序的情况下更改配置，那么是的，您可能想自己管理它；这不是正常情况。 3：您总是直接以明文形式提供某些内容，无论是密钥还是数据本身。

【解决方案2】：

我会亲自向用户解决您的软件可以通过 HTTPS 连接通过网络访问的远程密钥管理器。例如Keywhiz 或Vault 可能符合要求。

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

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

【讨论】：