为什么 Kubernetes 中的 Pod 会自动挂载服务帐户机密？

Question

需要了解为什么 Pod 会自动挂载服务帐户机密。

如果我们禁用服务帐户的自动挂载，这是否会影响我们的应用程序的任何操作，该应用程序已经在 pod 规范部分指定了服务帐户，但服务帐户的自动挂载未禁用。

Answer 1

链接文档中解释了如何禁用服务帐户的自动挂载：

在版本 1.6+ 中，您可以通过在服务帐户上进行设置来选择不自动挂载服务帐户的 API 凭据automountServiceAccountToken: false。

在 1.6+ 版本中，您还可以选择不为特定 pod 自动挂载 API 凭据。

还建议了一些解决方案来缓解安全问题：

• 使用RBAC

• 使用变异网络钩子

如果我们禁用服务帐户的自动退出，这是否会影响我们的应用程序的任何操作，该应用程序已经在 pod 规范部分指定了服务帐户

如果禁用 SA 密钥的自动挂载，Pod 将无法访问 K8s API 服务器或执行任何其他需要作为服务帐户进行身份验证的操作。很难判断这是否会影响您的工作量，只有您自己才能知道。仅与其他用户定义的服务通信的 Web 服务器或工作 Pod 可能在没有 SA 访问权限的情况下表现良好，但如果它们想要从应用程序 Pod 生成 K8s 作业，则它们将需要 SA。

但想了解为什么服务帐户的秘密会安装到 Pod，即使这是安全升级。

重点似乎是，就像计算机安全中经常出现的那样，我们需要权衡便利性与安全性。自动将 SA 秘密安装到 Pod 中可以轻松（=> 方便）使用 K8s API。默认情况下禁用此功能更安全，但也不太方便，因为您需要显式标记那些需要访问 K8s API 的 Pod。这是否是一个太大的负担很大程度上取决于工作量，并且可能没有适合每个人的默认答案。

为什么不将其更改为更安全的默认值？

这是在这里回答的：

默认情况下禁用不向后兼容，因此在（如果）创建 v2 Pod API 之前这不是一个现实的选择

和这里：

我并不是说这是不合理的，只是对于 Kubernetes 的 GA 发行版来说，这将是一颗难以下咽的药丸。我可以在 v2 pod API 中看到这种情况发生。