kubernetes名称空间中密码安全性的重要性？

Question

在使用Kubernetes（和Helm）设置自动化部署时，我多次遇到以下问题：

  

在单个名称空间中，服务密码（例如mysql）的安全性有多重要？

我的想法：这一点都不重要。为什么？无论如何，所有相关的Pod都包含密码，并且该服务在特定名称空间之外不可用。尽管某人可以访问该特定名称空间中的Pod，但是printenv可以满足他的所有需求。

我的特殊情况（Helm）：如果我根据需要设置了mysql服务器（requirements.yaml），则不必使用任何秘密或付出任何努力来共享mysql密码并可以在values.yaml中提供密码。

Answer 1

虽然Kubernetes机密不是 机密，但它们比Helm值更机密。从根本上讲，我建议这个问题更多的是关于您对数据库密码的信任程度，而不是任何特定的过程。我想到了三种方法：

1. 您是通过Helm值传递数据库密码的。 Helm并不是特别受访问控制的，因此可以helm install或helm rollback的任何人也可以{{ 1}}，然后找出密码。如果您不在乎这些人是否具有密码（所有部署都通过自动化系统运行；所有部署都由拥有所有密码的devops团队运行；您是一个由10个人组成的初创公司），那么这可以工作。

2. 数据库密码在受RBAC保护的Secret中。您可以使用Kubernetes role-based access control，以便普通用户无法直接读取Secrets的内容。某些管理员会创建Secret，然后Pod会挂载它或将其作为环境变量注入。现在，您不需要自己的密码即可进行部署，也无法轻松地提取它（但是，如果您可以启动任意容器，则将其转储出去的工作就不那么多了。）

3. 应用程序在启动时从某个外部来源获取数据库密码。 Hashicorp的Vault是我在这里使用的解决方案：Pod与Kubernetes服务一起运行帐户，使用该帐户从Vault获取令牌，然后使用该帐户获取数据库密码。 advanced version of this分发一次性使用的凭证，该凭证可以追溯到特定的Pod和服务帐户。这是最复杂的路径，但也是最安全的。