9

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

env:
- name: DB_PASSWORD
  value: password

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

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

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

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

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

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

4

2 回答 2

4

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

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

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

于 2015-08-31T18:10:21.550 回答
2

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

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

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

于 2015-09-05T02:52:26.947 回答