作者 | 戈皮纳斯·雷巴拉
译者| 张伟斌
规划| 丁小云
与过去相比，今天的企业必须更快地应对激烈的竞争压力，提高运营效率，适应外界持续的干扰。 实现这一目标的关键是在不牺牲可靠性、安全性或合规性的情况下实现更短的软件交付周期。 这正是集成 DevSecOps 策略的目标。 然而，当今的 DevSecOps 实施要求开发人员了解并参与交付管道，并在涉及安全问题时保持警惕，否则与网络犯罪和监管合规失败相关的风险可能会迅速增长。
GitOps 提供了一个解决方案。 通过将 GitOps 集成到 DevSecOps 工作流程中，企业可以利用 Git 显着简化软件交付工作流程，包括生产环境的发布，同时还可以在后台实现管道自动化并移交与安全和合规性相关的任务。 给相关团队。
GitOps的目标是使用Git作为事实来源来传递服务状态，以实现软件交付和基础设施配置。 GitOps 还可以通过开发人员熟悉的工作流程和工具来实现软件交付操作，使得 DevOps 流程几乎没有任何额外的障碍。
通过GitOps交付模型，企业安全团队可以指定适用于软件交付过程的安全策略，极大地提高了应用交付的安全性。 例如，安全团队可以要求将应用程序部署到特定环境来执行动态应用程序安全测试 (DAST) 并确保结果符合预期。
将此类安全策略声明为代码不仅可以作为安全策略的文档，而且还有助于对这些策略进行自动合规性检查。 此外，安全策略作为代码由独立于软件开发流程的安全团队进行管理，并与开发人员使用的工具集成，这可以显着提高所交付软件的安全性。
这种分离对于围绕软件发布开发零信任环境至关重要。 这可以通过在出现安全问题时暴露它们来加速新软件的交付，从而消除进行单独安全审查的时间和复杂性。
DevSecOps 基础知识
尽管与软件交付生命周期相关的风险不断增加，但大多数组织都在努力让其运营、产品开发和安全团队协作以提高安全性，而无需添加繁琐的流程步骤，避免最终减慢软件交付生命周期。 DevSecOps 基于以下原则在整个软件交付生命周期中建立这种协作：
目前流行的DevSecOps管道模型就符合这些原则。 AWS 和 Google Cloud 都为此方法提供了最佳实践。 使用 Spinnaker 等编排工具，对 Git 或其他源代码存储库的更改会触发自动化工作流程（“推送模型”），该工作流程会执行将应用程序部署到目标环境的必要步骤。 这些步骤通常表示为有向无环图，其中包含运行工作流中某个阶段/步骤的要求，以及基于该阶段的状态或输出运行的依赖阶段/步骤。 该模型允许所有利益相关者（开发、运营、安全、SRE 等）了解所有步骤。 它将规则/要求编码为护栏或大门，这些也暴露给交付生态系统中的所有利益相关者。
然而，这种管道模型给开发人员带来了巨大的负担，他们需要熟悉整个流程，包括如何使用和配置编排器。 这意味着需要严格的入职流程才能使开发人员能够使用该系统。
交付的 GitOps 模型
GitOps 模型使开发人员能够简单地在 Git 中提交代码。 他们不需要新工具来运行或跟踪交付过程中的任何内容。 他们不需要理解和使用编排器。 相反，SecOps 将必要的可见性、风险识别和规则执行放入 Git 中，使 Git 成为在后台运行且对开发人员不可见的所有必要流程控制的单一来源。
GitOps 模型依赖于 Kubernetes 的原生功能。 Kubernetes 支持以声明式模型运行应用程序软件安全实现，应用程序服务所需的配置可以在配置文件中以声明式规范的形式指定。 然后可以通过 Kubernetes API 应用这些规范，Kubernetes 将推断需要执行的操作以达到配置文件中声明的状态，并执行这些操作。 此模式允许检测 Git 中预期运行状态与实际运行状态之间的变化（偏差检测）软件安全实现，从而采取纠正措施。
Kubernetes 有一个扩展，可以扩展其基本功能，以允许进行额外的检查，作为部署要求验证的一部分。 Kubernetes 准入控制 (KAC) 机制在简化 GitOps 和提供交付所需的可靠性和安全性方面发挥着关键作用。
KAC 还提供了将流程所需的企业策略与开发流程分开的关键能力，从而允许策略更改独立于开发流程。 例如，为了确保与 SOX 合规要求的一致性，即确保不止一个人参与验证对生产环境的修改，准入控制策略可以验证 Git PR 审查和 QA 批准之前是否由两方完成允许部署。 由不同的人进行。
利用这些能力，GitOps模型可以实现以下功能：
这一模型对于开发人员来说的巨大优势在于，他们只需采取一步即可参与 DevSecOps 工作流程，即查找并协调目标环境中的更改。 在他们的 DevOps 流程中，无需执行安全检查、测试、设置策略或寻求批准等单独的步骤。
在 GitOps 模型中，可以要求 DevOps 工具异步执行其操作，而不是顺序编排步骤，然后在部署时验证是否已根据指定策略完成所需的步骤。
例如，代码签入执行持续集成（CI）单元测试，使开发人员能够拥有更快的开发/测试周期。 二进制扫描、动态扫描和其他策略检查与开发人员的工作流程异步发生。 测试用例可以自动运行，也可以手动完成集成测试，并将结果发布到同一个或另一个中央存储库。 存储在中央存储库中的结果与签名的二进制文件相关联，以方便验证。 这通常是通过 CI 的输出来完成的，例如可以签名的容器。 对于生产部署，Git 配置会使用新版本清单进行更新。
当新版本的配置更新到Git存储库时，将触发Kubernetes命名空间的部署。 然后，准入控制器的配置将触发基于容器签名元数据的检查，以确定是否允许部署。 这些检查将确定静态扫描、动态扫描、合规性要求（例如 SOX）和测试结果是否可以接受部署，从而批准或拒绝部署并向用户发送有关失败原因的通知。
开放策略代理 (OPA) 网关和 Kyverno 是用于部署准入控制检查的示例框架。 它们可以配置为 Kubernetes 的扩展，并包含开放策略代理或 Kyverno 来验证安全策略。 当应用新的应用程序或 Git 更改时，扩展会识别新的部署要求并运行安全策略检查以确定是否满足所有指定的安全性和合规性要求。 然后它可以批准部署或停止部署。
虽然这些都是帮助实现 GitOps 模型的优秀框架，但它们尚不支持以下功能：
这意味着虽然 GitOps 模型有可能使开发人员的生活变得更简单，但仍需要其他工具来实现实时可见性和协作能力。
在企业环境中，安全团队应该能够查看所有应用程序的合规性状态，包括为特定应用程序设置例外。 系统应该能够向开发人员组通知违规行为，并与安全团队合作解决特定问题，例如在已部署的应用程序中发现的新漏洞。 这些功能对于在不影响软件交付速度的情况下确保安全性至关重要。
速度在软件交付工作流程中至关重要。 但没有安全性和合规性的速度是鲁莽的。 DevSecOps 的 GitOps 模型提供了最佳解决方案。 它允许开发人员专注于他们的项目，而无需了解安全相关问题并学习在快速开发/测试周期中使用编排器工具，同时允许他们继续使用他们选择的原始工具。 此外，它还使 SecOps 能够在软件交付工作流程中添加所需的防护措施，并在出现风险时暴露风险，从而更快、更轻松地解决这些问题，从而实现更安全、更可靠的软件发布。 然而，我们还没有完全做到这一点，但在未来一两年内，预计会有大量解决方案进入市场，使真正的 GitOps 成为现实。
原文链接：
使用 GitOps() 加速安全软件交付生命周期
