☰

如何使用 kustomize 将机密信息排除在版本控制之外？

tag-icon • tag-icon kubernetes
如何使用 kustomize 将机密信息排除在版本控制之外？

我已经开始使用kustomize。它允许您使用以下方式生成机密：

secretGenerator:
  - name: mariadb-env
    envs:
      - mariadb.env

这很棒，因为 kustomize 附加了一个哈希这样，每次我编辑我的秘密时，kubernetes 都会将其视为新的并重新启动服务器。

但是，如果我将其kustomization.yaml置于版本控制之下，那么有点儿意味着我mariadb.env也将其置于版本控制之下。如果我不这样做，那么kustomize build x就会因为缺少文件而失败[对于任何试图克隆存储库的人来说]。即使我没有将其置于 VCS 之下，这仍然意味着我的开发工作站上有这些秘密文件。

在采用 kustomize 之前，我只需创建一次 secret，将其发送到 kubernetes 集群，然后让它在那里运行。我仍然可以通过名称在我的配置中引用，但有了哈希，我就不能再这样做了。但哈希对于强制重启也非常有用。

人们如何应对这个问题？

答案1

答案往往涉及机密的加密。这太过简单了，所以让我们进一步探讨一下，因为不同的解决方案对这个问题的处理方式截然不同。

根据我目前的研究，主要有两三种常用工具可以实现这一目标：

  • 封存的秘密
  • Helm-Secrets（特定于 Helm，但使用 Mozilla SOPS，它仅涉及机密和 YAML 等，因此不是 Kubernetes 特定的）
  • KSOPS（这是一个使用 SOPS 的 Kustomize 插件）

我目前还没有这方面的实际经验，但我可以告诉你，最大的区别之一是，使用 Sealed Secrets 时，解密是在 SealedSecret 对象进入系统时在集群内部完成的。密钥材料位于集群内部。加密的 SealedSecret（一种 CRD）可以安全地存在于 Git 中，无论你对加密有多大信心。开发人员不需要访问私钥，但没有私钥就无法查看机密的内容。

将其与 SOPS 进行比较，解密发生在客户端，并且秘密通常会保存在某些外部保险库中，例如 HashiCorp Vault、Amazon KMS 或类似保险库。

比较两者，一个重要的方面似乎是使用公共 CI/CD 基础设施，以及哪些方需要处理您的秘密；这是 Sealed Secrets 具有优势的一个领域，但无论哪种方式都有利有弊，特别是在您的所有/部分开发人员可能需要的访问权限方面。

毫不奇怪，SOPS（以其一种形式）和 Sealed Secrets 都被广泛使用，这也解释了为什么像 Kuberenetes（甚至是像 OpenShift 这样有主见的发行版）这样的系统对于如何做到这一点没有提出任何特别的意见；这令人沮丧！

如果您熟悉 Ansible Vault，则可以以类似的方式将 SOPS 与 PGP 密钥一起使用，并可能与其他 KMS 解决方案一起使用。

答案2

我一直在检查这个话题，我认为你可能想检查一下覆盖。覆盖只是另一种定制化，指的是基础，并指的是应用于该基础的补丁。

这种安排使得管理您的配置变得容易。

如果我们谈论的是一些 VCS，根据可能有文件来自上游存储库由其他人管理。覆盖可能你拥有的仓库. 这解释这里。

因此，您不需要mariadb.env在版本控制下存储。如果您愿意，您可以这样做，但那也可以是一组本地文件。

此外，您可能会在以下概述中找到有趣的想法“基于分支结构的布局”（但该概念侧重于 VCS 并且您说过您只希望在 VCS 中拥有部分代码）。

编辑。保险库和秘密更新后自动重启 pod

相关内容