【.com快速翻译】为复杂环境部署基础设施并不容易。这需要一致性和标准，以便基础架构可靠且可扩展。基础架构即代码(IaC)是简化此过程的一种方法。Terraform和CloudFormation等IaC工具允许开发人员编写代码来描述应如何配置基础设施，然后自动配置基础设施以满足定义，从而大大提高原本繁琐且耗时的过程的自动化——以防管理员在配置系统时出错，过程中也容易出现人为错误。但是IaC的力量带来了巨大的责任，因为其中涉及许多风险。本文概述了IaC模板中最常见的五个风险以及如何缓解它们。1.硬编码秘密或资源引用如果信息过于敏感、不可查看或随时间变化（例如密钥、代码、IP地址、域名、别名或帐户名），则应为其分配适当名称的变量。根据经验，出于安全目的，不应将此类信息硬编码到版本控制中。这也很不方便，因为如果我们轮换一些密钥或秘密，就需要一个新的提交和审查阶段：如果部署不当，这个阶段可能会被阻止或延迟数小时甚至数天。相反，将所有此类数据存储在专用服务中，根据需要注入所需的秘密或上下文变量。在典型情况下，当创建基础设施计划并提交部署时，我们使用AWSSecretsManager或Vault作为示例来捕获这些值。这允许通过适当的访问控制和审计更安全地处理机密信息。2.将状态文件提交到版本控制对于Terraform的用户来说，状态文件是在启动IaC程序时创建的项目。它们包含针对特定基础架构的有用元数据和配置选项。敏感值更可能存储在状态文件中并提交给版本控制，这是可以理解的。当其他人试图从版本控制中检出代码时，这会产生其他问题。状态文件可能已过时或不完整。他们最终可能会部署难以安全回滚的错误或不安全的基础架构组件。共享和重用状态文件的最佳方式是在远程状态位置（通常是远程存储服务，如AWS的S3）共享状态文件，并实施适当的权限机制。3.部署前后不执行完整性和安全性检查在使用模板或状态计划之前，您可以选择根据当前基础设施部署对其进行验证。这将有助于捕获任何语法错误；但最重要的是，在此过程中可能会添加任何意外的重大更改。此外，部署完成后，应该进行额外的完整性和安全性检查，以回答最常见的问题：部署的基础设施是否安全？部署是否留下了开放的端口？部署是否未损坏未使用的资源？第一步是在部署后编写验收测试以验证常见的安全假设（参见TaskCat和Terratest）。此外，应该有一个自动化系统（例如PrismaCloud）定期检查环境以检测任何偏差并报告安全问题。4.使用不受信任的图像或插件使用旧的或未知的图像和实例，如果它们存在漏洞，可能会带来安全风险。如果您使用来自第三方的IaC插件（例如，使用Terraform时经常出现这种情况），也会出现同样的问题。仅仅因为它们是开源和公开的并不意味着它们值得信赖和可靠。事实上，除非内置全面的安全检查，否则它们会带来重大的安全风险，因为它们可能会在运行时泄露数据或执行不安全的部署。图像或插件的功能在实际使用之前应该经过仔细的同行评审和评估。5.不重用代码并将所有内容放在一个文件中将所有配置和模板放在一个文件中是一种灾难，因为它们可能无法协同工作。增加配置数量会导致大量重复代码。这种代码重复会导致难以理解的模板，从而导致更多的配置漂移，最终可能会出现在生产环境中。IaC模板应按环境和逻辑边界进行组织，例如生产、开发和暂存环境，它们有自己的数据库、VPC、权限和IAM策略模板。每次使用公共引用和共享模块都有助于更加自信和一致地部署基础设施资源。结论从上面的场景可以清楚的了解到IaC模板是源代码，需要作为源代码来对待。这实际上意味着，在将这些模板提交到版本控制系统之前，每次都应该对这些模板进行多人审查、质量评估、格式化和验证。一些组织政策应该尽早制定。只有这样，我们才能确保避免大量错误以及让未经检查的代码投入生产的风险。遵循良好的工程实践并密切关注始终有助于从源头上避免这些风险。原标题：基础设施即代码模板中的5个常见风险，作者：TheoDespoudis
