策略即代码是根治多云配置混乱的良方吗？

策略即代码是根治多云配置混乱的良方吗？

当配置文件被编写成代码时，开发人员可以快速自信地按照公司标准使用他们已经熟悉的工具进行工作。

译自 Is Policy as Code the Cure for Multicloud Config Chaos? 。

在公有云和私有云之间托管软件，目前在管理和安全方面本质上比简单的托管范式更难以管理和更不安全——毫无疑问。IBM 2022 年的数据泄露报告指出，15% 的泄露仍然是由于云配置错误所致。

同年，Osterman Research 和 Ermetic 的一份白皮书将检测一般的云配置错误(如未加密的资源和多因素认证)置于组织云成熟度高的关注事项清单之首。

向多云的转移在环境和 IT 的每个层面之间创建了隔阂。IT 运维团队花费宝贵的时间来缓解跨部署基础设施和配置错误的服务带来的负面影响——都使用不同的工具，对他们要执行的策略没有可见性。

但是，有一种更好的方式来管理云，并确保策略执行到位：策略即代码。策略即代码(有时称为 PaC)是一种开发方法，它使用代码而不是硬编码来表达基础设施和应用程序行为策略。

这意味着可以重复使用这些策略来自动执行跨域一致的配置——如安全性、合规性、基线等。策略即代码可以在整个软件开发生命周期中实施配置，而不仅仅依赖于手动检查和流程。

尽管 PaC 对 DevOps 明显有益，但它在行业内仍然不是常见做法——很少被用作解决云配置混乱等糟糕情况的工具。让我们详细说明 PaC 如何帮助弥合当今的云配置差距。

策略即代码在多云配置中的力量

• 利用 PaC，一个规格实际上可以适用所有。策略即代码被用来统一公有云和私有云，以简化管理和加快每个云提供的软件、资源和服务的扩展。
• 策略即代码可以在 IT 的多个层面上标准化一个可治理的过程，从中央 IT 和基础设施一直到应用程序开发者。它通过使您的策略可见、可审计和可共享来实现这一点。
• 策略即代码通过将配置(从基线到部署)与战略业务目标保持一致来支持业务预期。
• 策略即代码让开发人员做他们最擅长的事情：编写代码。向开发人员添加配置就是要求他们在舒适区之外工作。这可能会破坏开发人员的体验，导致困乏和流失，从而使您的其他问题更加严重。
• 策略即代码通过将合规责任从负担过重的个人转移到自动执行的可重复代码上，以确保更高的安全性。

简单，对吧？那么为什么组织没有实施策略即代码?

当组织开始将服务迁移到公有云时，大多数组织没有考虑此举的长期影响。过去几年揭示了云迁移对他们花费如此长时间在地面上建立的标准化流程的持久影响:

• 大瘟疫迫使对服务和资源的可用性需求激增，这压倒了谨慎。
• 成本抽象吸引了注重底线和商业领导者。
• 云可用性的服务级别协议本应该使内部安全保证过时。
• 云给各行各业的组织提供了“保持竞争力”的机会，因为早期采用者看到了一系列好处。

开发人员也帮助推动了对云的部分狂热。应用层面的开发人员需要云的灵活性(自由选择工具和工作流程的自由)。只有后来组织才意识到，他们与公司政策的脱离导致了跨混合部署的配置错误，使一个本已混乱的范例更加复杂。

即使是逐步进行的云回迁也只会加剧这些问题。今天，一些组织正在缩减他们的云部署，或者通过将主机托管返回组合来使其多样化。但该组合仍然缺乏有效管理所有这些所需的标准化。云回迁远非解决方案，事实上，它是与跨部署基础设施相关的问题的加剧因素。

只要组织一只脚踏实地，一只脚在云端——只要他们用不同的工具集 obscure 他们的云配置方法——云配置错误将继续制约他们的混合云操作的潜力。缺乏标准化将继续导致业务问题，如安全漏洞、未经授权的访问、肆意飘移、资源效率低下、不合规和数据丢失。

如何开始建立策略即代码实践

通过逆向工程来为您的基础设施创建 PaC 是最佳方式。首先定义您的理想状态，识别在通往那里的路上您将发现的潜在风险和差距，并制定一个框架来缓解这些风险。

以下是一些建议，帮助您开始建立一个 PaC 方法，以在任何部署的环境中强制执行所需状态，以获得更好的基础设施和更好的 DevOps:

不要在新工具上花费大量资源。PaC 并非关于重造轮子——而是关于利用您拥有的工具和流程(如基础设施即代码)在所有基础设施上执行可重复状态。强大的自动化和配置管理是 PaC 的核心，因此使用您已经拥有的工具来建立 PaC 方法。

定义您的数据中心、多云和混合云基础设施的期望状态。识别可能导致配置漂移的潜在风险区域，如合规性错误，并通过状态强制绘制一条返回期望基础设施配置的道路。通过 PaC 的期望状态强制，您可以预先防止甚至跨部署基础设施中的配置错误。

使您的基础设施与其支持的业务目标保持一致。在创建 PaC 时，护栏至关重要，以将您的努力集中在最需要的地方。从您的基础设施管理之旅开始：考虑您组织中谁需要基础设施资源，他们的基础设施主要用例是什么，以及他们在哪里以及如何消费基础设施。将这些需求映射到第 0 天(供应)、第 1 天(配置管理)和第 2 天(状态强制和合规性)，以建立一个强大的 PaC 框架，支持您的整个 DevOps 周期。

测试您的 PaC。从业务目标和风险评估的角度测试您的基础设施配置管理和状态强制，以确保它能做您希望它做的事情。

您的云基础设施管理不会自行变得更简单

不能指望开发人员在自己的工具中处理策略实施。当他们可以依赖作为代码编写的配置文件时，他们可以快速自信地按照公司标准工作，使用他们已经知道的工具，而不是玩弄功能代码以使其在他们的层面符合要求。

通过 PaC，您的团队可以支持云中的开发人员的需求和不断变化的合规性期望，以帮助您实现最初迁移到云的原因。