![如何使用 kustomize 将机密信息排除在版本控制之外?](https://linux22.com/image/753516/%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8%20kustomize%20%E5%B0%86%E6%9C%BA%E5%AF%86%E4%BF%A1%E6%81%AF%E6%8E%92%E9%99%A4%E5%9C%A8%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6%E4%B9%8B%E5%A4%96%EF%BC%9F.png)
我已经开始使用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