基础设施漂移不仅仅是技术上的小麻烦；它是一个普遍存在的问题，如果不加以控制，会危及整个组织。
译自 How to Control Cloud Infrastructure Drift，作者 Eran Bibi。
基础设施漂移对于大规模管理云资源的组织来说是一个普遍的挑战。虽然基础设施即代码 (IaC) 提供了一种部署和维护基础设施的结构化方法，但当更改发生在 IaC 工作流之外时，仍然会发生漂移。这并非一定是异常行为——由于外部承包商、需要快速解决的高压情况（例如事故）或判断失误或权限过大的工具，这都可能随时发生。
虽然我们总是渴望保持完美的 IaC 卫生和完美的 GitOps 流程，但不幸的是，这几乎是痴人说梦，而且不可能强制执行。 实际上，我们看到过度依赖ClickOps(或通过点击软件工具中的各种选项手动执行任务，这对于可能不熟悉编码或脚本的用户来说更容易访问)。而这个手动过程往往是基础设施漂移的原因。基础设施漂移是指云中基础设施的实际状态与在 IaC 工具（如Terraform）中定义的期望状态之间的差异。这种差异可能导致安全漏洞、可靠性问题和运营效率低下。
在 Firefly，我们每天通过我们的系统扫描和处理超过 55,000 个云帐户。在此过程中，我们每月处理近 320,000 次漂移，因此我们真正了解基础设施漂移问题的巨大规模和影响。我们还发现，90% 使用 IaC 的大规模部署都会遇到漂移，而其中约有一半的情况未被发现。对于这些组织来说，无论是在可靠性、安全还是运维方面，都会有 100% 的负面影响。
尽管人们越来越了解需要减轻基础设施漂移的影响，但它仍然如此常见的原因有很多。许多原因都源于大规模云基础设施的日常维护以及高速和高压的交付周期。
基础设施漂移发生的常见原因包括：
- 手动紧急修复: 在事故或紧急情况下，工程师通常会通过云控制台或 API 直接更改基础设施。这些更改可以解决紧急问题，但可能会绕过 IaC 管道，从而导致漂移。
- 遗留资源: 中途采用 IaC 的组织可能拥有手动或使用不同工具创建的现有资源。这些未管理的资源容易发生漂移，因为它们不在 IaC 治理范围之内。
- 具有权限的自动化工具: 例如云安全态势管理 (CSPM)之类的工具可能具有修改配置（例如安全组）的权限。当这些工具在 IaC 工作流之外进行更改时，就会引入漂移。
- 部分 IaC 采用: 一些组织选择性地实施 IaC，只使用 IaC 管理新的或特定的项目，而旧的或不同的资源则手动管理。这种不一致会导致环境之间出现漂移。
- 环境不一致: 虽然生产环境通常受到严格控制，但暂存和开发环境可能允许开发人员有更大的灵活性。这些环境中的手动更改可能会造成差异，尤其是在配置不匹配的情况下。
- IaC 和云 API 不一致: 云提供商经常更新其 API 和服务，如果 IaC 工具没有更新以匹配，则可能导致漂移。这种不一致会导致 IaC 部署与当前云状态出现偏差。
即使是最先进的工程组织，也无法避免手动紧急修复。然而，虽然这些更改可以解决紧急问题，但它们会绕过 IaC 管道，从而导致差异。此外，在其云旅程中中途采用 IaC 的组织可能拥有在 IaC 治理范围之外创建的遗留资源，这使得它们容易发生漂移。自动化工具（例如 CSPM 系统）可能具有修改配置（例如安全组）的权限；这些工具在 IaC 工作流之外进行的更改可能会导致进一步的差异。
基础设施漂移可以采取多种形式，通常始于小的变化，然后逐渐演变成重大的差异。 例如，考虑一个通过 Terraform 管理的 AWS 身份和访问管理 (IAM) 策略，当有人添加像星号 (*) 这样简单的字符到策略中时，就会发生漂移，这会将权限从只读扩展到完全访问。类似地，在 Kubernetes 环境中，IaC 中具有只读权限的角色可能会在实际集群中修改为包含写入和删除权限——这可能会导致大量的生产问题。这些看似微小的调整可能会危及安全并导致意外访问。
当漂移未得到检查时，它会带来超出轻微不便的风险。
我们 2024 基础设施即代码报告 的数据显示，它经常未得到检查。基础设施漂移不仅经常未被发现地潜伏着，即使被发现，也没有立即得到修复。令人担忧的是，13% 的情况下，基础设施漂移根本没有被修复。
除了停机的主要风险之外，未解决的漂移还会影响基础设施的稳定性和安全性。例如，当权限或配置在 IaC 之外发生更改时，它可能会打开攻击者可能利用的漏洞。如果基础设施的实际状态与在预发布环境中测试的所需配置不匹配，漂移还会影响服务可靠性。总而言之，漂移不仅仅是一个技术问题，它还会危及整个组织。
有效管理漂移需要强大的监控和检测，以及行之有效的方法来尽快减轻漂移。
以下是一些检测和管理漂移的实用技巧：
-
漂移监控：Terraform 的
plan或 Pulumi 的preview命令可用于检测漂移，通过命令行界面 (CLI) 运行 AWS CloudFormation 的drift detection命令也可以。通过安排定期检查，团队可以将当前基础设施状态与所需配置进行比较。如果检测到漂移，退出代码将指示差异，使团队能够相应地做出反应。 - Kubernetes 的 GitOps：对于 Kubernetes 环境，Argo CD 和 Flux 等 GitOps 工具会持续协调集群状态与存储在 Git 中的配置。这些工具有助于确保任何未经授权的更改都会迅速恢复，从而保持与 Git 中的事实来源的一致性。
- 漂移检测工具：Driftctl 和 KubeDiff 等开源工具提供有针对性的漂移检测功能。Driftctl 与 Terraform 等 IaC 工具配合良好，而 KubeDiff 则针对 Kubernetes 配置进行了优化。
- 实时警报和路由：建立警报机制对于有效的漂移管理至关重要。通过将 IaC 工具与 Slack 或 PagerDuty 集成，团队可以接收漂移的实时通知，从而能够快速解决问题。
这些是检测漂移的好方法，但目标必须是修复漂移。
修复漂移主要有两种形式：使云环境与 IaC 保持一致，或更新 IaC 以反映实际状态。在手动更改是临时修复的情况下，重新应用 IaC 配置可以恢复所需状态。但是，如果手动更改代表必要的调整，最好更新 IaC 模板以与实际状态保持一致，从而防止漂移再次发生。
如果您刚开始使用漂移检测，则可以使用 Terraform 的简单监控脚本来获得有关差异的宝贵见解。尽管这种基本方法可能无法扩展到大型部署，但它对于较小的设置或作为概念证明是有效的。对于大型环境，Firefly、driftctl 或 GitOps 框架等工具提供了更强大的解决方案，用于处理企业级基础设施的复杂性。
基础设施漂移是云环境中持续面临的挑战，但通过正确的工具和实践，组织可以保持对其基础设施的控制。
通过利用 IaC、主动监控漂移和实施 GitOps 等策略，团队可以最大限度地减少漂移的影响，确保基础设施保持一致并符合组织的需求。定期漂移检测和及时修复最终将提高云操作的安全性和可靠性以及效率，使团队能够以现代公司所需的速度充满信心地交付。