Helm Charts 中的秘密管理

我正在尝试使用Helm charts在 Kubernetes 集群中安装应用程序。有人可以建议什么是更好的秘密管理解决方案吗？使用helm secrets是个好主意或者Hashicorp Vault?

Vault 在技术上非常棒，但它可能会成为管理负担。无论“秘密”是什么，您都可以获得强有力的保护；您可以通过生成一次性密码来避免共享神奇的秘密，例如您的中央数据库密码；如果您需要签名或加密的内容，您可以要求 Vault 为您做这件事，而不必自己知道加密秘密。最大的缺点是它是一个单独的服务来管理，从中获取秘密并不是完全无缝的，如果您需要重新启动服务器，您有时需要管理员来解封它。

Kubernetes 秘密实际上只是具有不同名称的 ConfigMap。使用默认设置，操作员可以很容易地获取 Secret 的值（kubectl get secret ... -o yaml，然后对字符串进行 Base64 解码），所以它们实际上并不是那么秘密。如果您有一个有趣的命名空间设置，则通常无法访问不同命名空间中的 Secret，这可能意味着被迫大量复制 Secret。仅使用本机工具，例如kubectl管理Secrets也有点笨拙。

通过 Helm 推送凭证可能是最无缝的路径 - 从 Helm 值转换为 Secret 对象以推送到容器中非常容易，并且很容易从 CI 系统等地方推送值 - 但也是最不安全的路径。除了能够通过以下方式转储值之外kubectl你也可以helm get values在 Helm 版本上查找值。

因此，问题在于保守秘密有多重要，以及您想要投入多少努力。如果您想要无缝集成并且可以限制授权操作员对集群的访问并有效地使用 RBAC，那么 Helm 值可能会很好足够的。如果您可以投资技术上最好且最复杂的解决方案，并且您想要它的一些高级功能，那么 Vault 效果很好。维护简单的 Kubernetes 秘密是一种中间立场，它比使用 Helm 更安全，但不太易于管理。