Kubernetes 机密和服务帐户答案

【问题标题】：Kubernetes secrets and service accountsKubernetes 机密和服务帐户
【发布时间】：2018-07-23 14:36:27
【问题描述】：

在过去的 6 个月里，我一直在使用 Kubernetes，我们已经部署了一些服务。

我们即将部署另一个存储加密数据并将密钥放入 KMS 的设备。这需要两个服务帐户，一个用于数据，一个用于密钥。

必须审核对此的数据访问。由于对这些数据的访问非常敏感，我们不愿意将两个服务帐户都放在名称命名空间中，就好像以任何方式受到损害一样，攻击者可以在未经审计的情况下访问数据和密钥。

现在我们有一个密钥，另一个我们将手动发布到单个 pod。

这太可怕了，因为它需要一个人信任这个密钥，并且限制了可扩展性。幸运的是，这项服务的流量非常小。

有没有其他人遇到过同样的问题？你是怎么解决的？

干杯

【问题讨论】：

【解决方案1】：

必须审核对此的数据访问

如果您启用audit logging，则通过此服务帐户完成的每个 API 调用都会被记录下来。如果您的服务从未通过 API 调用，这可能对您没有帮助，但考虑到您有一个正在使用的服务帐户，听起来确实如此。

现在我们有一个密钥，另一个我们将手动发布到单个 pod。

您可以考虑为此使用Vault。如果您将机密存储在 Vault 中，您可以使用 this 之类的东西将环境变量作为环境变量自动推送到 pod 中。这比您的过程涉及更多一点，但要安全得多。

您还可以将 Vault 与 Google Cloud KMS 一起使用，详见 this article

【讨论】：

【解决方案2】：

您所描述的内容很常见 - 使用 Kubernetes 机密中的密钥/服务帐户/身份来访问外部机密存储。

我对双密钥概念有点困惑 - 通过在秘密和 pod 中都拥有一个密钥，您可以获得什么？如果机密被泄露，那么 etcd 就会被泄露，你就会遇到更大的问题。我建议您改为专注于锁定机密、使用审计日志以及使密钥易于轮换以防万一。

需要考虑的一些事项：

如果您主要使用 Kubernetes，请考虑将（加密）机密存储在 Kubernetes secrets 中。
如果您在 Kubernetes 外部集中存储机密（如您所描述的），请考虑仅使用单个 Kubernetes 机密 - 您将获得 Kubernetes 审核日志以访问机密（请参阅推荐的 audit-policy）和云用于密钥使用的 KMS 审核日志。

【讨论】：

也许我没有正确描述问题，我们将服务帐户存储在秘密中，而不是在 pod、git 或其他任何东西中。问题是任何获得命名空间访问权限的人都可以读取机密并绕过我们的审计日志访问数据存储和 KMS。因此，我们添加了一个 API 端点，因此第二个密钥可以发布到 pod，仅保留在本地内存中。
知道了。 Kubernetes 审计日志将正常记录对该密钥的请求。如果攻击者可以访问机密（而不是通过前门），那么您是正确的，它不会被审计记录。