在使用 Kubernetes（和 Helm）设置自动化部署时，我多次遇到以下问题：
单个命名空间内的服务密码（例如 mysql）的安全性有多重要？
我的想法：这根本不重要。为什么？无论如何，所有相关的 pod 都包含密码，并且服务在特定命名空间之外不可用。尽管有人可以访问该特定命名空间中的 pod，但printenv 会为他提供所需的一切。
我的具体案例（Helm）： 如果我将 mysql 服务器设置为要求（requirements.yaml），我不必使用任何秘密或努力共享 mysql 密码并且可以在 values.yaml 中提供密码。
【问题讨论】：
标签： kubernetes kubernetes-helm
虽然 Kubernetes 机密不是 机密，但它们比 Helm 值更机密。从根本上说，我建议这个问题更多的是关于您对数据库密码的信任程度，而不是任何特定过程。我想到了三种方法：
您通过 Helm 值传递数据库密码。 Helm 不是特别受访问控制的，因此任何可以helm install 或helm rollback 的人也可以helm get values 并找出密码。如果您不关心这些人是否有密码（所有部署都通过自动化系统运行；所有部署都由拥有所有密码的 devops 团队运行；您是一家 10 人的初创公司），那么这很有效。
数据库密码在RBAC保护的Secret中。可以使用Kubernetesrole-based access control，普通用户无法直接读取Secrets的内容。一些管理员创建 Secret，Pod 将其挂载或作为环境变量注入。现在你自己不需要密码就可以部署，而且你不能随便提取它（但如果你可以启动任意容器，把它转储出来也不是什么工作量）。
李>应用程序在启动时从某个外部来源获取数据库密码。 Hashicorp 的 Vault 是我在这里使用的解决方案：Pod 使用 Kubernetes 服务帐户运行，它用于从 Vault 获取令牌，然后使用它来获取数据库密码。 advanced version of this 分发一次性凭证，可以追溯到特定的 Pod 和服务帐户。这是最复杂的路径，但也是最安全的。
【讨论】：