如何使用 GitOps 从源头应用安全性

如果您的GitOps 部署模型存在安全问题（例如，由于拼写错误而配置错误的权限），这将被传播，直到希望在运行时发现它，在那里扫描或找到大多数安全事件。

如果您可以从源头解决基础架构中的潜在安全问题，该怎么办？

让我们从基础开始。

什么是 Git？

Git是一个开源的分布式版本控制系统。它跟踪文件（通常是文本文件，如源代码）中所做的更改，从而允许和促进协作工作模型。它是当今版本控制系统中的_事实上的_标准。

您可以在笔记本电脑上本地拥有自己的 git 存储库，将其托管在自己的服务器上，或使用一些提供商，例如 GitLab 或 GitHub。

关于如何管理存储库（git-flow、github-flow 等）有不同的“流程”，但是关于如何使用 git 的一个基本示例是这样的：文件中的更改由用户“提交” “分叉”存储库并在“分支”中进行适当的更改。

然后，用户创建一个请求（“拉取请求”、“合并请求”或只是“发送补丁”）以将这些更改包含在存储库中。

之后，通常会在“所有者”和创建请求的用户之间进行讨论，如果一切正常，则接受更改并将其添加到存储库中。

注意：如果你想了解更多，这里有更多关于 git pull request 机制的详细信息。

要查看真实世界的示例，只需浏览您最喜欢的开源 GitLab 或 GitHub 存储库并浏览“拉取请求”（或“合并请求”）选项卡（或查看这个有趣的选项）。您可以查看提议的更改、评论、标签、提议更改的人员、针对提议的更改运行验证的工具、发送给查看存储库的人员的通知等。

什么是 GitOps？

简而言之， GitOps 只是一种方法，它使用 git 存储库作为软件资产的单一事实来源，因此您可以将 git 部署模型（拉取请求、回滚、批准等）用于您的软件。

有书籍（ GitOps 之路、 GitOps 和 Kubernetes或GitOps 云原生持续部署）、白皮书和更多的博客文章，我们无法计算，但让我们通过快速浏览一下事物的演变来详细说明GitOps的目的在过去的几年里。

在云之前，添加新服务器来托管您的应用程序需要数周时间。您必须请求权限、购买并执行大量手动任务。然后，虚拟化让事情变得更加容易。您请求具有某些规格的虚拟机，几分钟后，您可以访问它。

然后，云。请求服务器、网络、存储，甚至数据库、消息队列、容器、机器学习、无服务器……只需一个 API 调用！你请求它，几秒钟后，你得到它，就像那样。你只需要为你使用的东西付费。这也意味着基础设施可以作为执行 API 调用的代码进行管理……您将代码存储在哪里？在 git 存储库（或任何其他内容版本系统）中。

GitOps 术语由 Weaveworks 在 2017年创造，并解释OpenGitOps ，一个 GitOps 系统基于以下原则：

• 声明式：它定义了“什么”。
• 版本化和不可变：因此是“git”。
• 自动拉取：代理观察期望的状态和代码中发生的变化。
• 不断和解：有人提到 Kubernetes 吗？

GitOps 方法的本质基本上是在集群上运行的一个 Kubernetes 控制器或多个控制器（或代理），它观察在其上运行的 Kubernetes 对象（由CustomResource定义）将当前状态与 Git repo 中指定的状态进行比较。如果不匹配，它会通过应用在存储库中找到的清单来修复应用程序。

注意：GitOps 的方法略有不同，例如推送与拉取、如何处理配置管理等。这些都是高级主题，但现在，让我们坚持基础知识。

下图显示了一个简化的 GitOps 系统：

• 用户将代码更改提交到 Git 存储库。
• 然后，在存储库上触发一个流程以将这些更改合并到应用程序本身中，包括针对该新代码运行自动化工具以对其进行验证。
• 一旦一切就绪，运行在 Kubernetes 集群中的 GitOps 代理（它正在观察存储库）执行所需状态（存储库中的代码）和当前状态（运行在 Kubernetes 集群本身上的对象）之间的协调。

基于 Git 对开发人员来说意味着顺畅。他们不需要担心要与之交互的新工具，而是应用用于管理 Git 存储库中代码的相同实践。

说到 GitOps 工具，已经有一些可用的工具，包括Flux或ArgoCD等开源工具，它们都是CNCF 孵化项目。

为了通过 GitOps 了解应用程序定义的样子，这是一个由 Flux 或 ArgoCD 管理的简单应用程序（存储在 GitHub 存储库中）的示例。

使用助焊剂：

 --- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: GitRepository metadata: name: my-example-app namespace: hello-world spec: interval: 30s ref: branch: master url: https://github.com/xxx/my-example-apps.git --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: my-example-app namespace: hello-world spec: interval: 5m0s path: ./myapp prune: true sourceRef: kind: GitRepository name: my-example-app targetNamespace: hello-world

使用 ArgoCD：

 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-example-app namespace: hello-world spec: destination: namespace: my-example-app server: https://kubernetes.default.svc project: default source: path: myapp/ repoURL: https://github.com/xxx/my-example-apps.git targetRevision: HEAD syncPolicy: automated: {} syncOptions: - CreateNamespace=true

两者都引用了存储应用程序清单的 Git 存储库（部署）、命名空间和更多细节。

GitOps 与 IaC

基础架构即代码是一种使用不同技术和工具将基础架构的构建块视为代码的方法。这意味着您无需通过您最喜欢的基础架构提供商 Web 界面手动创建基础架构（例如 VM、容器、网络或存储），而是将它们定义为代码，然后由您选择的工具创建/更新/管理这些基础架构，例如如terraform 、 crossplane或pulumi等。

好处是巨大的。您可以像管理代码一样管理您的基础架构（现在是代码），并将您的开发最佳实践（自动化、测试、可追溯性、版本控制等）用于您的基础架构资产。事实上，有一种趋势是使用“基础设施即软件”作为一个术语，因为它不仅仅是代码。

关于这个主题有大量信息，但以下资源是一个很好的起点。

正如您可能已经想到的那样，GitOps 利用基础设施即代码作为声明性模型来定义基础设施。事实上，IaC 是 GitOps 的基石之一！但这更多是因为 IaC 并没有强制执行 GitOps 的其余原则。

GitOps 与 DevOps

“DevOps”术语有很多定义。这取决于你问谁，但简单地说，“DevOps 是实践和工具的结合，用于构建和交付软件，减少摩擦并实现高速化。”

DevOps 方法可以利用 GitOps，因为 GitOps 提供了一个与 DevOps 实践相匹配的框架，但这并不是绝对必要的。

NoOps 呢？

NoOps 是 Forrester 在2021年创造的，它是一种处理操作的激进方法，其中 IT 环境被抽象和自动化到无需手动管理的程度。

GitOps 通过修复Git 存储库中具有所需状态的那些来帮助减少手动更改，但在整个 IT 环境中应用真正的 NoOps 是一个理想的目标，而不是今天的真正目标。

GitOps 仅适用于 Kubernetes 吗？

不。Kubernetes、控制器模式和定义 Kubernetes 对象的声明性模型是 GitOps 方法的完美匹配，但这并不意味着没有 Kubernetes 就不能应用 GitOps 方法。如果在 Kubernetes 之外使用 GitOps 会遇到一些挑战，例如处理幂等性、资产的删除/创建、秘密管理等。但GitOps 原则可以在没有 Kubernetes的情况下应用（并应用一点创造力）。

GitOps 与安全

现在让我们谈谈安全方面。大多数安全工具在运行时检测潜在的漏洞和问题（为时已晚）。为了修复它们，要么需要执行响应式手动过程（例如，使用 kubectl edit 直接修改 k8s 对象中的参数），要么理想情况下，修复将在源头发生，并将在整个供应链中传播。这就是所谓的“安全左移”。从为时已晚解决问题到在问题发生之前解决问题。

这并不意味着每个安全问题都可以从源头解决，但直接在源头添加安全层可以防止一些问题。

首先，适用一般安全建议。

• 减少攻击面
• 加密秘密（使用外部秘密或密封秘密）
• 网络分段
• RBAC
• 保持软件最新
• 强制执行最小权限
• 监控和测量
• …

让我们看看 GitOps 方法可以总体上提高您的安全性的几个场景：

• 避免/拒绝手动更改（避免漂移） 。 Git 存储库是事实的来源。如果您尝试修改应用程序定义，GitOps 工具将通过应用存储在 Git 存储库中的版本来恢复这些更改。

• 回滚更改。想象一下，您通过修改应用程序部署中的某些参数在特定提交中引入了潜在的安全问题。利用 Git 功能，如果需要，您可以直接在源头回滚更改，GitOps 工具将在无需用户交互的情况下重新部署您的应用程序。

• 反应快。如果您发现您在应用程序中使用了易受攻击的容器镜像（例如 MariaDB），您只需创建一个 PR 将标签更新到部署文件中，GitOps 工具就会在新部署中使用新标签。

• 可追溯性。使用 Git 功能，您可以轻松检查文件何时更改、更改本身以及促进更改的用户。你有一个免费的审计日志。

• 灾难恢复。同样，Git 存储库是事实的来源。如果您因为发生某些事情而需要重新部署您的应用程序，那么定义就在那里（当然，您需要为其他内容（例如数据本身）制定灾难恢复计划）。
• 访问控制。您可以对 Git 存储库中的不同用户应用不同的权限，甚至可以使用诸如“仅在两次正面评价后合并更改”之类的策略。

这些好处足以证明使用 GitOps 方法来改善您的安全状况是合理的，而且它们是开箱即用的，但 GitOps 是其他一些东西的组合。我们可以做得更多。 GitHub、GitLab 和其他 Git 存储库提供商允许您根据您在 Git 存储库中执行的更改（包括拉取请求）运行操作或管道，因此可能性无穷无尽。几个例子：

• 起绒。应用程序的定义是 code ，如果检查定义是否有语法错误、缺少参数等等怎么办？有一些工具（例如megalinter ）可以针对您执行的更改执行，这样您就可以避免以后出现意外。

• 测试。您甚至可以自动创建一个临时 Kubernetes 集群来运行您的应用程序并对其进行一些测试。

• 漏洞扫描。通过在将它们部署到您的环境中之前检查您正在使用的容器映像是否存在漏洞。

• 策略即代码。利用OPA ，您甚至可以将策略应用于清单以检查潜在问题或自定义策略

最后的想法

GitOps 方法为部署模型和安全优势带来了一些改进，而无需添加其他工具。

它通过直接向源代码添加“左移”层来改善安全状况，并且由于拉取请求模型的灵活性，您可以轻松添加额外的安全检查，而不会影响或修改运行时。

也在这里发布。