使用kubernetes填充敏感信息的Docker容器
我有一个运行容器的容器，需要访问API密钥和数据库密码等敏感信息。 现在，这些敏感值被embedded到控制器定义中，如下所示：
env: - name: DB_PASSWORD value: password 然后在Docker容器中作为$DB_PASSWORD环境variables使用。 一切都相当简单。
但是阅读他们关于秘密的文档，他们明确地说，将敏感的configuration值放入您的定义中违反了最佳实践，并且可能是一个安全问题。 我能想到的唯一的其他策略是：
- 为每个用户社区或命名空间创build一个OpenPGP密钥
- 使用crypt将configuration值设置为etcd（使用私钥encryption）
- 创build一个包含私钥的kubernetes秘密， 像这样
- 将该秘密与容器相关联（意味着私钥可以作为卷装入）， 就像这样
- 当容器启动时，它将访问卷装载中的私钥文件，并使用它来解密从etcd返回的conf值
- 这可以被合并到confd中 ，根据模板定义填充本地文件（比如Apache或者WordPress的configuration文件）
这看起来相当复杂，但更加安全和灵活，因为这些值将不再是静态的并以明文存储。
所以我的问题，我知道这不是一个完全客观的问题，这是否是完全必要的？ 只有pipe理员能够首先查看和执行RC定义; 所以如果有人违反了kubernetes大师，还有其他问题需要担心。 我看到的唯一好处是，秘密不会以明文方式提交给文件系统。
有没有其他的方法来以安全的方式填充Docker容器的秘密信息？
除非你有很多兆字节的configuration，否则这个系统听起来不必要的复杂。 预期的用法是将每个configuration置于一个秘密中，而需要该configuration的pod可以将该秘密安装为一个卷。
然后你可以使用各种机制中的任何一种将configuration传递给你的任务，例如，如果是环境variablessource secret/config.sh; ./mybinary source secret/config.sh; ./mybinary是一个简单的方法。
我不认为你通过存储私钥作为秘密获得任何额外的安全。
我将亲自解决使用远程密钥pipe理器，您的软件可以通过HTTPS连接在networking上访问。 例如Keywhiz或Vault可能适合这个法案。
我将在一个单独的隔离子网上托pipe密钥pipe理器，并将防火墙configuration为只允许访问我期望需要密钥的IP地址。 KeyWhiz和Vault都带有一个ACL机制，所以你可能根本不需要对防火墙做任何事情，但是考虑到它并没有什么坏处，但是这里的关键是把keymanager托pipe在一个单独的networking上，一个单独的主机提供商
容器中的本地configuration文件只包含密钥服务的URL，并且可能需要从密钥pipe理器中检索密钥的证书 – 如果攻击者不符合ACL / IP地址，证书将毫无用处。