为什么GitOps对DevSecOps至关重要

译者 | 朱钢 审校 | 梁策 孙淑娟 DevOps在自动化、可追溯性方面的优势已得到广泛认可，此外它还能助力从前孤立的团队和利益相关者展开协作。但是，随着 DevOps 团队越来越多地承担将运营转移到容器化的Kubernetes 环境的任务，久经考验的 DevOps 实践也可能棋差一着。如今，安全和风险问题正以不同的方式表现出来。 好消息是，在分布式环境的安全方面，GitOps 填补了 DevOps 中的许多空白。 由于GitOps 流程非常有利于 DevSecOps，此处定义为适用于整个应用程序生命周期的安全最佳实践。 在本文中，我们将了解 GitOps 如何为 DevSecOps 提供基本框架，在整个 CI/CD 以及 Kubernetes 集群上应用程序管理部署后的阶段进行安全检查。

单一不变的事实来源

GitOps 可以定义为： Kubernetes 和其他云原生技术的运营模型，它提供一组最佳实践，统一容器化集群和应用程序的 Git 部署、管理和监控。 它是实现开发人员管理应用程序经验的途径;其中，端到端 CI/CD 管道和 Git 工作流应用于运营和开发。 正如此处声明了所需的配置， Git 是单一的事实来源。 Kubernetes 内部运行了一个 GitOps 代理，它不断将 Kubernetes 内部的实际状态与存储在 Git 中的所需状态进行比较。 任何合并到 Git 中受监控分支的新更改都会自动应用于 Kubernetes。 相反，任何直接应用于 Kubernetes 的手动更改都会自动恢复到 Git 中声明的所需状态。配置漂移得到了消除。 由于其不可变的结构，Git 通常被描述为适用于 GitOps 的单一事实来源。除其他事项外，它还有助于维护一个边界(与防火墙不同)，该边界将 CI 和 CD 之间的问题分开。通过这种方式，作为CI的一部分，应用程序开发中涉及的步骤数量(拉取请求，测试，提交等) 在Git上保持独立。 对于提出拉取请求的开发人员，拉取请求在审查和批准后会被合并，并在下一次协调时自动应用于集群(一般需要 15 分钟)。 默认情况下，该过程是双向的——这意味着当下一个协调循环运行时(通常每 15 分钟一次)，直接对 Kubernetes 所做的更改会在 Git 上得到响应。但是，当 DevOps 团队成员或非法行为入侵者直接对集群进行更改时，这种情况并不理想。这些直接到集群的更改没有通过合并请求和批准，因此违反了 GitOps 原则，即当发生漂移时 Git 作为不可变的事实来源。 作为一种帮助减少漂移发生的解决方案，GitOps 监控工具可以在对集群作出更改而未先在 Git 中应用时发送警报。当这种情况发生时，由于审计跟踪，通过运行时环境中处于部署状态的控制器，Git 上的应用程序代码可以替换对集群所做的错误更改。 相反，如果不变性没有实现，就会发生漂移。这可能在网络攻击的情况下发生，或 DevOps 团队成员无意更改了集群配置，使其与 Git 上的配置不同。出现这种情况时，使用适当的 GitOps 工具能够将不一致标记出来，从而代表 GitOps 流程提供的典型 DevSecOps。 适当的工具可以自动执行持续监控的过程，以确保 Git 存储库中配置的所需状态与 Kubernetes 集群中的实际状态相匹配。 一旦它们在存储库的声明状态中正确提交，就会用于协调和完成部署。

审计控制

GitOps 提供的审计功能也是 DevSecOps 支持的关键。 通过保留在 Git 存储库中作为单一事实来源，所有应用程序、代码和配置都进行了版本控制，并保留了完整的审计跟踪，这是任何安全环境的主要要求。此审计跟踪通常也可供开发人员和运营团队成员使用，以便他们观察集群中正在运行的内容(大多数用户仅限于只读访问集群配置)。 开发人员不一定需要像运营和 DevSecOps 团队成员那样依赖审计跟踪，但他们可以利用这种能力来了解发生了哪些变化以及对存储库进行更改的动机是什么。简而言之，对于开发人员 (以及所有 DevOps 团队成员)一切都只是一个 Git 日志的问题。 Git 上的审计跟踪也可供开发人员在需要时轻松查找。这是因为系统的完整历史记录在 Git 记录系统中，开发人员可以理解这一点。 借助审计跟踪的可用性，开发人员还可以轻松回滚导致问题的应用程序的更改。 当集群遭到破坏或配置错误时，这尤其有用。 在这种情况下，审计跟踪无需从头开始重建集群，而是在存储库中包含所需的状态， 然后部署具有审计跟踪所需状态的集群配置和应用程序，并自动重建过程。

很少有“万能钥匙”

开发人员通常依靠 Jenkins(一种自动化服务器)来构建、测试和支持用于 Kubernetes 环境生产管道的 CI/CD。如果没有 GitOps，开发人员在直接部署代码时可能会直接访问 Kubernetes 集群。换句话说，无论他们属于组织内部还是作为远程工作的承包商，这对开发人员来说可谓有了一把直接访问生产环境的“万能钥匙”，但这不是一个理想的安全方案。 在上述情况下，只要错误的用户(或更糟糕的入侵者)使用 KubeConfig 或 Kubectl 命令访问生产环境中的集群，这些集群就可以从笔记本电脑上访问。如果攻击者破坏了 CI 系统和凭据集，那么他们还可以访问 CI 系统有权访问的任何群集。 GitOps 有助于防止用户(或攻击者)在不留下任何痕迹的情况下更改群集配置，这一点对于运营和安全团队尤其重要，此外还有助于减轻开发人员的心理负担。例如，通过访问控制，开发人员通常不应该直接访问 Kubernetes 节点和/或 kubectl 命令行。因此，GitOps 可以协调开发人员在 Git 中定义的任何内容，但除非开发人员具有特殊的访问控制权限，否则不允许手动访问 Kubernetes 集群或生产环境。 GitOps 的 DevSecOps 功能是阻止 CD 攻击媒介场景的一种方式，从而保护这把”万能钥匙”。当GitOps运算符(如开源 Flux，下面将对此进行详细介绍)在 Kubernetes 内部运行时，可以访问集群，访问控制仍保留在 Kubernetes 安全框架中。用户访问权限是通过向不同团队和团队成员的命名空间分配权限来确定的。 美国国防部(DoD)提供了一个有效利用DevSecOps和GitOps 的例子。最近，美国空军首席软件官尼古拉斯·查兰(Nicolas Chaillan)讲述了DevSecOps和GitOps如何与Flux一起在支持整个美国空军保安部队的软件开发中发挥了关键作用。 查兰表示，“安全和保障是不可让步的问题，但我们也希望开发人员能通过自助服务提高生产力并加快速度。” 美国国防部表示，GitOps是“在整个国防部成功构建和推出‘平台一号’(Platform One)的关键”。平台一号是“一个经过批准，完全与云原生计算基金会(CNCF)的Kubernetes发行版兼容，同时还有基础设施即代码的剧本以及强化容器的集合”，具有内置的安全管道。

制衡

DevSecOps 流程与 GitOps 集成，提供制衡。因为所有拉取请求都经过评审，所以通过这种方式，它提供的访问控制可以防止开发人员或入侵者访问源代码存储库，从而在CI过程中引入后门，零日漏洞或其他类型的漏洞。 由于 DevSecOps 支持 CI 进程，因此在 Git 上提交代码并部署在群集中之前就已进行检查和平衡。开发人员通常会将更改作为拉取请求提交，该请求会经过评审。一旦经过审查和批准，代码就会合并到 Git 上，然后相应地更改所需状态的 YAML 文件。 所需的状态将自动应用于 Kubernetes 集群。如上所述，具有 DevSecOps 功能的适当 GitOps 工具会持续监控目标系统内的实际状态，以确保它响应 Git 上声明的内容。如果有任何差异，则会发出警报，因此可以采取纠正措施。

DevSecOps 自成一派

许多GitOps工具都支持DevSecOps。例如，开源 Flux 有助于维护 Git 存储库，使其成为单一不可变的事实来源。Flux 的功能还扩展到访问控制，以便在 CI/CD 期间对提交和部署的代码进行检查和平衡。 对于更有个性的 Flux 体验，开源 Weave GitOps Core 让帮助跨多个集群自动化 CI/CD的起始步骤更简化。此外，使用Weave GitOps Core设置GitOps和DevSecOps的过程涉及控制台上的一些简单命令。 Weave GitOps Enterprise 已成为第一个 GitOps 平台，该平台可在任何规模的混合云、多云和边缘架构中为 Kubernetes 自动执行持续应用程序交付和自动化运营控制。 所有这三个工具都有助于自动执行监控，以确保群集配置始终与 Git 上的内容匹配，从而帮助防止漂移。完整且可访问的审计跟踪允许根据需要回滚应用程序和群集配置，而无需从头开始重建群集。 总而言之，GitOps代表了分布式Kubernetes环境的DevOps的演变，而在整个应用程序生命周期中，DevSecOps已成为维护GitOps的CI / CD安全性的重要方式。