借助 GitOps 实现快速、安全的软件交付生命周期

跟过去相比，如今的企业必须要更快地响应激烈的竞争压力，提高运行效率，并适应来自外界的持续破坏性。达成这一目标的关键是实现越来短的软件交付周期，并且不能以牺牲可靠性、安全性或合规性为代价。这正是集成 DevSecOps 策略的目标。但是，如今的 DevSecOps 实现需要开发人员理解并参与交付流水线的搭建，并且需要在涉及安全问题时保持警觉，否则与网络犯罪和法规合规性失败相关的风险会迅速增长。

GitOps 提供了一个解决方案。通过将 GitOps 集成到 DevSecOps 工作流中，企业可以利用 Git 的优势大幅简化软件交付工作流，包括生产环境的发布，同时还可以在后台自动化搭建流水线，并将安全性和合规性相关的任务交给相关团队。

GitOps 的目标是以 Git 作为交付服务状态的事实来源（source of truth），实现软件交付和基础设施的配置。GitOps 还可以通过开发人员熟悉的工作流和工具来实现软件交付的操作，使 DevOps 流程几乎没有任何额外的障碍。

通过 GitOps 交付模式，企业安全团队可以指定适用于软件交付流程的安全策略，这极大地提升了应用交付的安全性。例如，安全团队可以要求部署到特定环境的应用要执行动态应用安全性测试（dynamic application security test，DAST），并确保检查结果符合预期。

将这样的安全策略声明为代码的方式，不仅可以作为安全策略的文档，还有助于这些策略的自动化合规检查。此外，安全策略作为代码，会由独立于软件开发过程的安全团队管理，并且与开发人员使用的工具进行集成，这可以显著提升所交付软件的安全性。

这种分离对于围绕软件发布开发一个零信任的环境至关重要。在安全问题出现时，通过将其暴露出来，这能够加速新软件的交付，从而消除了进行单独安全审查的所耗费的时间和复杂性。

尽管与软件交付生命周期相关的风险在不断增加，但是大多数的组织都在努力让他们的运维、产品开发和安全团队进行协作，以提升安全性，同时不增加繁琐的流程步骤，避免最终减缓软件交付的生命周期。DevSecOps 基于如下原则在软件交付生命周期中建立了这种协作：

• 在整个软件交付工作流中提供对安全问题的可见性 安全团队、开发人员和项目经理应该都能看到综合安全性测试的结果，包括应用安全性测试（application security test，SAST）、动态应用安全性测试（dynamic application security test，DAST）、模糊测试、依赖性扫描和二进制扫描、许可证合规性和 secret 探测。

• 在软件交付生命周期中尽早发现安全问题 风险和漏洞越早发现，就能越快、越容易进行补救。我们应该使用自动化来消除对构建、测试、部署和生产阶段所产生的大量日志和度量指标的手工审查。

• 在整个工作流中实现安全策略的自动执行 应用安全包括确保生产环境的软件符合不断变化的监管需求，尤其是与数据隐私相关的需求，并减少违规的风险。它还包括确保版本符合内部策略，如部署前的所有审查步骤。

目前流行的 DevSecOps 的流水线模型符合了这些原则。AWS 和 Google Cloud 都为这种方法给出了最佳实践。使用编排器工具，如 Spinnaker，Git 或其他源码仓库的变更会触发一个自动化的工作流（“推送模型”），该工作流会通过必要的步骤将应用程序部署到目标环境。这些步骤通常表示为有向无环图（directed acyclic graph），其中包含运行工作流中某个 stage/step 的要求，以及基于该阶段的状态或输出而运行的依赖 stage/step。该模型允许所有的利益相关者（开发、运维、安全、SRE 等）对所有的步骤实现可见性。它将规则 / 需求编码为护栏（guardrail）或闸门（gate），这也会暴露给交付生态系统中的所有利益相关者。

但是，这种流水线模型给开发人员带来了巨大的负担，他们需要熟悉整个流程，包括如何使用和配置编排器。这意味着它需要一个苛刻的任职流程，才能让开发人员有能力使用该系统。

GitOps 模型能够让开发人员只需简单地在 Git 中提交他们的代码即可。他们不需要在交付过程中使用新的工具来运行或跟踪任何东西。他们不需要理解和使用编排器。相反，SecOps 能够将必要的可见性、风险识别和规则执行放到 Git 中，使 Git 成为所有必要的流程控制的唯一来源，这些流程控制在后台运行，对开发人员不可见。

GitOps 模型依赖于 Kubernetes 的原生能力。Kubernetes 支持以声明式模型运行应用程序，应用程序服务所需的配置可以作为声明式规范在配置文件中指定。然后，可以通过 Kubernetes API 应用这些规范，Kubernetes 会推断出为达到配置文件中声明的状态需要执行的操作，并执行这些操作。这种模式允许检测 Git 中的预期状态和实际运行状态之间的变化（漂移检测），从而实现纠正措施。

Kubernetes 有一个 扩展功能，可以扩展其基本功能，允许将额外的检查作为部署需求验证的一部分。Kubernetes 准入控制（Kubernetes Admission Control，KAC）机制在简化 GitOps 并为交付提供所需的可靠性和安全性方面发挥了关键作用。

KAC 还提供了一项关键的能力，将流程要求的企业策略与开发流程区分开来，允许策略变化独立于开发流程。例如，为了确保与 SOX 合规性的要求保持一致，也就是确保有一个以上的人参与验证对生产环境的修改，在允许部署之前，准入控制策略可以验证 Git PR 审查和 QA 批准是由两个不同的人进行的。

利用这些能力，GitOps 模型可以实现如下功能：

• 配置监控 运维团队可以在 Git 仓库中声明配置，然后通过监控 Git 配置变化的控制器模块将该配置应用到目标环境中。控制器还可以监控目标环境，检测与 Git 中所声明配置的漂移，然后同步至目标环境，使应用程序符合预期的配置。

• 自由使用 IDE 和 Git 工具 后台的规范允许在交付过程中使用适当的闸门和护栏。这使得开发人员可以继续使用他们熟悉的工具，同时还能够达到软件交付所需的安全性和可靠性等级。

这种模式对开发人员的巨大优势在于，他们只需要采取一个步骤即可参与 DevSecOps 的工作流，即在目标环境中寻找变更并进行协调（reconcile）。在他们的 DevOps 流程中，不需要执行像安全检查、测试、设置策略或寻求批准这样的独立步骤。

在 GitOps 模型中，可以要求 DevOps 工具异步地执行它们的行动，以代替顺序的编排步骤，然后在部署时，验证所需的步骤是否均已经按照指定的策略执行完成。

例如，代码检入（check-in）执行持续集成（CI）的单元测试，允许开发人员拥有更快的开发 / 测试周期。而二进制扫描、动态扫描和其他策略检查是与开发人员的工作流异步进行的。测试用例可以自动运行，或手动进行集成测试，并将结果发布到同一个或另外的中央仓库中。存储在中央仓库中的结果会与已签名二进制制品相关联，以便于进行验证。这通常是通过 CI 的输出来完成的，例如，一个可以进行签名的容器。对于生产环境的部署，Git 配置会随着新的版本清单而进行更新。

当新版本的配置更新到 Git 仓库时，将会触发 Kubernetes 命名空间的部署。然后，准入控制器的配置 将触发基于容器签名元数据的检查，以确定是否允许部署。这些检查将确定静态扫描、动态扫描、合规性要求（如 SOX）和测试结果是否可以接受部署，从而批准或拒绝部署，并向用户发送关于失败原因的通知。

开放策略代理（Open Policy Agent，OPA）网关和 Kyverno 是实现部署准入控制检查的示例框架。它们可以被配置为 Kubernetes 的扩展，并包括一个开放策略代理或 Kyverno，以验证安全策略。当一个新的应用程序或 Git 变更得到应用时，该扩展会识别新的部署需求，并运行安全策略检查，以确定是否满足所有指定的安全性和合规性要求。然后，它可以批准部署或停止部署。

虽然这些都是帮助实现 GitOps 模型的优秀框架，但它们还不支持以下功能：

• 集中审计各种异步运行的工具所执行的交付检查

• 修改和查看策略的接口，并将其应用于不同类型的应用程序和 Kubernetes 集群。

• 对运行在各种 Kubernetes 集群上的应用程序及其安全状态、解析需求等的可见性。

这意味着，尽管 GitOps 模型有可能使开发人员的生活更简单，但还需要额外的工具来实现实时可见性和协作的能力。

在企业环境中，安全团队应该能够查看所有应用程序的合规状态，包括为特定的应用程序设置例外。系统应该能够通知开发人员组的违规行为，并与安全团队合作解决特定问题，例如，在已部署的应用程序中发现的新漏洞。这些功能对于在不影响软件交付速度的前提下确保安全性至关重要。

软件交付工作流中的速度是至关重要的。但没有安全性和合规性的速度是鲁莽的行为。用于 DevSecOps 的 GitOps 模型提供了最好的方案。它可以让开发人员专注于他们的项目，而不必了解安全性相关的问题，并在快速的开发 / 测试周期中学习使用编排器工具，同时允许他们继续使用原来所选择的工具。另外，它可以使 SecOps 在软件交付工作流中添加所需的护栏，并在风险出现时将其暴露出来，从而更快、更容易地解决它们，以实现更安全、更可靠的软件发布。只不过，我们还没有完全达到这个目标，但在未来一两年内，预计会有大量的解决方案进入市场，使真正的 GitOps 成为现实。

原文链接：

Accelerating the Secure Software Delivery Lifecycle with GitOps(https://www.infoq.com/articles/secure-software-development-gitops/)

相关阅读：

Palantir 如何构建基于 GitOps 的内部开发者平台 (https://www.infoq.cn/article/oXfRwTYaDp4RUdXfei54 )

GitOps 是皇帝的新衣吗？(https://www.infoq.cn/article/E2Nk6iYClH4RL8aNCRDB )

为什么说可观察性是解锁 GitOps 的关键 (https://www.infoq.cn/article/TTDS1pC6Cz6MRqJTpMir )

声明：本文为 InfoQ 翻译，未经许可禁止转载。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！