使用GitOps管理k8s secret

1. 写在前面

原文链接

GitOps是伴随着云原生产生的一个新的概念，它的核心是以一种声明式的方式管理资源，表示当前的状态，让你在任何时候都能知道git中的情况，并将这种声明式的状态解析为集群。

我们在GitOps上犯的最大错误是结构。仓库的结构至关重要，你选择如何在公司里组织GitOps，将决定它的成败。

当你解决了结构问题之后，我们面临的下一个最大的问题就是如何保证Secret的安全。一般来说，最后的结果是人们有不需要的访问权限，或者有一个共享的Secret，通过Slack或1Password传来传去。

Sealed Secrets是Kubernetes上解决Secret的一种流行方式，它是一个不错的解决方案，依靠PKI和共享公钥来加密，并在集群上安装私钥。

本文将尝试解释如何使用GitOps来管理k8s的Secret资源。

2. 管理Secret比较好的方式

Mozilla的SOPS。

SOPS支持多种来源的密钥输入，包括AWS KMS、GCE、Vault、PGP等。它提供了使用AWS KMS的外部密钥作为输入来加密和解密秘密的能力，但它也支持Shamir的Secret共享和密钥组，本质上允许对解密所需的密钥以及这些密钥的数量进行策略。

由于SOPS让我们有能力使用AWS KMS这样的服务，我们可以控制谁有加密和解密的权限，但这也意味着我们可以利用AWS的实例配置文件，让机器做它们设计时最擅长的事情，通过自动化让我们的生活更轻松。

最后一个我想提请大家注意的功能是，一旦文件被加密，所有关于如何加密的元数据都是文件本身的一部分，不需要第三方服务、数据库、隐藏目录或二级文件来知道如何解密文件。

Flux对SOPS有一流的支持。

3. 结构

一开始我就说过，正确架构你的仓库是至关重要的。这一点来源于个人在工程实践中总结的一些经验之谈，对于不同的场景，您可能需要权衡一下我这里的"最佳实践"。

对于结构化化来说，通常可以简单的分成两个部分：

• 仓库中内容的布局
• 使用仓库的数量

在我的项目中，我通常会使用三个库：

• 定义集群运行所需的每一个基础资源
• 处理工程团队负责的产品的所有发布
• 给Secret使用

项目中我只使用了SOPS与专用的Secret库，使用Flux和SOPS使我们获得了这种能力，具有前所未有的灵活性。

3.1 目录结构

|-- .sops.yaml
|-- secrets
    |-- dev (environment/cluster)
        |-- database.yaml