如果你曾在 DevOps 团队工作过，典型的工作流程如下：通过 CI 推送应用程序代码 pipeline然后使用 kubectl、Terraform 或 Ansible 等 GitOps 工具单独处理基础设施。这就是典型的 DevOps：构建、测试、部署，并且通常手动或使用脚本管理基础设施。
现在进入 GitOps。有了 GitOps，一切，包括部署、基础设施和访问规则，都在 Git 中声明。不再 kubectl 应用 或手动运行 Terraform。Git 将成为生产环境的接口。您提交 PR，ArgoCD 或 FluxCD 等 GitOps 工具会自动将您所需的状态同步到集群。
GitOps 与 DevOps 的关键转变
- DevOps： CI/CD pipeline推送到集群
- GitOps： 集群从 Git 中提取所需状态
这是一个微妙却又至关重要的区别。CI 仍然负责构建和测试，但有了 GitOps，CD 就由 Git 驱动了。你的 PR 将成为生产环境的变更。
GitOps 如何改变开发人员对部署、基础设施和访问的控制
部署
在传统的 DevOps 中，部署意味着运行 pipeline 作业或输入命令，例如 kubectl apply -f 部署.yaml。
在 GitOps 中，流程发生了变化。你可以编辑如下清单：
您创建了一个 PR。CI 检查运行（kubeval、yamllint、策略检查）。合并后，您的 GitOps 工具会自动同步状态。现在可以通过 Git 历史记录和 PR 评审来追踪部署情况。
基础设施（Terraform）
DevOps 团队经常运行 地形计划 和 地形应用 手动或 pipeline 脚本。在 GitOps 中，Terraform 代码变更是通过 PR 进行的。一旦获得批准，它们就会触发操作员或自动化作业以声明方式应用变更。
示例：更新 EC2 实例类型或安全组。整个生命周期通过 Git 变得可见和控制。
智能门禁
在 DevOps 中，访问依赖于 IAM 角色和令牌。审计线索分散在 CI 系统和云日志中。
在 GitOps 中，访问权限的变更是通过版本化清单进行的。例如：
合并的 PR 授予或撤销权限，并且每个更改都会记录在 Git 中。
GitOps 安全风险：为什么 Git 会成为你的生产环境攻击面
GitOps 将控制权集中在 Git 中，但这也扩大了攻击面：
恶意或意外的 PR
PR 可以回滚到易受攻击的图像 (图片：最新) 或无意中暴露服务 (类型：负载均衡器 不受IP限制）。
RBAC 升级
不安全的 YAML 可能会授予过多的权限，例如绑定 pipeline 服务帐户 集群管理员。
漂移和同步失败
外部变化（例如， kubectl补丁) 或操作员故障可能会导致配置漂移。如果没有同步警报，问题可能会被忽视。
这些问题说明了 GitOps 与 DevOps 面临的关键安全挑战：当 Git 存储库成为生产接口时，必须在每个环节都强制执行安全性 commit。访问控制中的失误或不安全的 PR 可能会立即影响到正在运行的基础设施。
真实事件：GitOps 中的 RBAC 配置错误
- 发生了什么事： 一位初级开发人员通过 PR 合并了 Helm 版本升级。它无意中引入了权限提升的 ClusterRoleBinding。ArgoCD 已同步此代码。
- 它带来了什么风险： Grafana 已向公众开放；开发团队被授予完全集群访问权限。
- 解决方式： 在事件响应期间通过安全扫描检测到。团队添加了渲染的 Helm 验证，并对基础设施进行了更严格的 PR 审批。
因为 Git 现在是一个生产界面， guardrails 至关重要。
面向开发人员的 GitOps 安全检查表
| 安全实践 | 该怎么办 | 为什么重要 |
|---|---|---|
| 分支保护 | 在主要内容上执行 PR 审查和状态检查 | 防止未经授权或未经验证的生产变更 |
| 签名 Commits | 需要 GPG 签名 commit并验证身份 | 确保可追溯性和责任制 |
| 舱单验证 | 向 CI 添加 YAML、RBAC 和 Helm 验证 pipelines | 阻止不安全的配置并避免漂移 |
| 范围批准 | 使用 CODEOWNERS 来限制谁可以批准基础设施和 RBAC 变更 | 限制过度宽泛的访问风险 |
| 漂移检测 | 启用 ArgoCD/FluxCD 同步并发出状态不匹配警报 | 识别手动更改或操作员故障 |
| 审核记录 | 将 GitOps 工具与日志堆栈集成（例如 Loki + Grafana） | 了解同步事件和 PR 到生产历史记录 |
团队应该用 GitOps 取代 DevOps 吗？
没有，GitOps 并不是 DevOps 的替代品；而是一种补充。
- DevOps = 构建/测试 pipelines、工件生成、安全扫描。
- GitOps = 管理 什么 被部署， 协调和 基础设施如何保持现状.
最佳实践？使用 CI (DevOps pipelines) 创建工件并运行测试。使用 GitOps 工具进行持续交付 (CD) 和基础设施管理。这样您就可以获得一致的部署、清晰的审计和以开发人员为中心的工作流程。
需要了解的 GitOps 工具
| 工具 | 最适合 | 安全说明 |
|---|---|---|
| 阿尔戈CD | 视觉工作流程 | 强制实施 RBAC、SSO 和 HTTPS |
| FluxCD | Git 原生自动化 | 限制 Git 访问，限制机密 |
| 编织 GitOps | 多集群管理 | 强制执行租赁边界 |
| 头盔 | 复杂/第三方应用程序 | 验证 values.yaml，避免泄露机密 |
| 自定义 | 清洁覆盖层 | 通过基础/覆盖清晰度避免漂移 |
Git 安全常见问题解答
阅读我们的 Git 安全常见问题解答，了解每位开发者都应该知道的内容！
真实案例：错误配置的 GitOps Repo 控制生产
这种情况表明，在 GitOps 与 DevOps 模式下，事情升级的速度有多快。一个使用 webhook 集成存储库的团队缺乏适当的 guardrails维护人员拥有写入权限，并且没有分支保护。服务被意外翻转到 类型：负载均衡器，将其公之于众。 ClusterRoleBinding 在同一个 repo 中授予了过多的权限。
由于像 ArgoCD 这样的 GitOps 工具会在合并后立即应用更改，因此错误配置会自动传播。该仓库实际上已成为生产 API。
为了恢复，团队锁定了基础文件的合并权限，实施了 RBAC 策略的合并前验证，并通过 GitOps 工具针对任何不同步状态配置了警报。这个例子凸显了 GitOps 与 DevOps 相比，如果没有稳固的控制，交付速度可能会成为一种负担。
修复
- 锁定权限：只有高级 DevSecOps 可以合并基础设施 PR
- 添加验证器：CI 阻止了包含不允许的 RBAC 规则的清单 PR
- 监控同步：当 ArgoCD 推送更改时发出警报
- 旋转图像标签：强制图像签名或使用 SBOM 扫描仪
Xygeni 如何在不中断开发人员工作流程的情况下增强 GitOps 安全性
西吉尼 解决了 GitOps 中的一个常见盲点：在代码审查中漏掉或在部署后悄然消失的风险变更。 合并之前，Xygeni 扫描 pull requests 对于安全问题，例如 ClusterRoleBinding 至 集群管理员，通过以下方式公开的服务 负载均衡器 没有 IP 限制，YAML 中的硬编码机密， .ENV或 Terraform 文件，使用 图片：最新或未经验证的容器镜像。它还能检测基础设施定义中的开放端口，例如将 SSH 暴露给公共互联网的安全组。
如果一个 pull request 违反安全策略的，Xygeni 可以自动阻止或标记。例如，它可以强制 集群IP 允许在生产环境中提供服务，拒绝授予过多权限的 PR，或要求所有容器镜像都包含 软件物料清单（SBOM). 秘密、错误配置的访问规则以及无法追踪的图像在进入生产之前也会被捕获。
代码合并后，Xygeni 会持续监控 Git 和 GitOps 活动。它可以检测对受保护分支的直接编辑、Git 代码库中未经授权的权限更改，以及由 ArgoCD 或 FluxCD 触发的意外同步，尤其是在正常工作时间之外或涉及关键清单的同步。
结果是更强大的控制力和更少的意外。Xygeni 让您能够清晰地了解部署的内容、批准人员以及部署如何与您的安全保持一致。 standard所有这些都不会中断开发人员的工作流程。快来试试吧！
结论：GitOps 不会取代 DevOps，但它会改变开发人员必须保护的内容
GitOps 并非 DevOps 的替代品，而是一种演进。在 GitOps 与 DevOps 模型中，CI 仍然专注于构建和测试，而 ArgoCD、FluxCD 或 Weave GitOps 等 GitOps 工具则负责管理交付和基础设施状态。
这种转变使 Git 仓库本身成为你运行时的一部分。如果它不安全，你的生产环境也会不安全。理解 GitOps 与 DevOps 对于构建安全的 pipelines，使用正确的 GitOps 工具可确保从一开始就内置可见性、执行力和审计。
当 Git 驱动生产时， code security 成为运营安全。如果您拥有代码库，那么您就拥有集群。使用将 Git 视为新的运行时接口的工具和实践来保护两者。
