为什么GitOps对DevSecOps至关重要。但随着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上保持独立。对于提出pullrequest的开发者，pullrequest在审核通过后合并，并在下次对账时自动应用到集群（通常需要15分钟）。默认情况下，该过程是双向的——这意味着直接对Kubernetes所做的更改会在下一个协调周期运行时（通常每15分钟一次）在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的示例。最近，美国空军首席软件官NicolasChaillan描述了DevSecOps和GitOps以及Flux如何在支持美国空军安全部队的软件开发方面发挥关键作用。“安全和保障是不容谈判的问题，但我们也希望开发人员通过自助服务提高生产力和速度，”Charan说。根据DoD的说法，GitOps是“在整个DoD中成功构建和推出‘PlatformOne’的关键”。PlatformOne是“经过批准的、完全集成的CloudNativeComputingFoundation(CNCF)Kubernetes发行版兼容的，以及基础设施即代码剧本和强化容器的集合”，具有内置的安全管道。检查和平衡与GitOps集成的DevSecOps流程，提供检查和平衡。因为所有的pullrequest都会被审核，通过这种方式，它提供的访问控制可以防止开发者或入侵者访问源代码仓库，从而在CI过程中引入后门、零日漏洞或其他类型的漏洞。由于DevSecOps支持CI过程，因此在Git上提交代码并在集群中部署之前完成检查和平衡。开发人员通常将更改作为拉取请求提交，并进行审查。一旦审查和批准，代码将合并到Git上，并根据YAML文件进行相应的更改。所需状态将自动应用于Kubernetes集群。如上所述，具有DevSecOps功能的适当GitOps工具将持续监视目标系统内的实际状态，以确保它响应Git上声明的内容。如果有任何差异，则会发出警报，以便采取纠正措施。DevSecOps独树一帜许多GitOps工具都支持DevSecOps。例如，开源Flux有助于将Git存储库维护为单一不变的真实来源。Flux的功能还扩展到访问控制，以便在CI/CD期间检查和平衡代码提交和部署。为了获得更加个性化的Flux体验，开源WeaveGitOpsCore简化了初始步骤，以帮助跨多个集群自动化CI/CD。此外，使用Wea??veGitOpsCore设置GitOps和DevSecOps的过程涉及控制台上的一些简单命令.WeaveGitOpsEnterprise已成为第一个GitOps平台，可在混合云、多云和边缘架构中以任何规模启用Kubernetes自动化持续应用程序交付和自动化操作控制。这三个工具都有助于自动化监控，以确保集群配置始终与Git上的配置相匹配，从而有助于防止漂移。完整且可访问的审计跟踪允许需要回滚应用程序和集群配置，而无需从头开始重建集群。总而言之，GitOps代表了DevOps对分布式Kubernetes环境的演进，而DevSecOps已经成为维护GitOpsCI/CD全生命周期安全的重要方式。译者介绍朱刚，51CTO社区编辑，2021IT影响力专家博主，阿里云专家博主，2019CSDN博客之星Top20，2020腾讯云+社区优秀作者，11年一线开发经验，曾参与猎头服务网站架构设计、企业智能客服及大型电子政务系统开发，主导建设某大型央企内部防泄密及电子文档安全监控系统，目前在北京途家从事医疗软件研发健康。原标题：WhyGitOpsiscrucialforDevSecOps，作者：SteveWaterworth
