【51CTO.com快译】为复杂环境部署基础架构并非易事。这需要一致性和标准，以便基础架构可靠、可扩展。基础架构即代码(IaC)是简化这个过程的一种方法。
Terraform和CloudFormation之类的IaC工具允许开发者编写描述应如何配置基础架构的代码，然后自动配置基础架构以满足定义，为原本繁琐又费时的过程大大提高了自动化程度——万一管理员在配置系统时犯了错误，这个过程还很容易出现人为错误。
但是IaC带来强大功能的同时带来了重大的责任，因为涉及很多风险。本文概述了IaC模板中五个最常见的风险以及如何化解风险。
1. 硬编码秘密或资源引用
如果信息太敏感、不可查看，或随着时间而变化(比如密钥、代码、IP地址、域名、别名或帐户名)，应为其分配具有适当名称的变量。作为一条经验法则，出于安全目的，不应将此类信息硬编码到版本控制中。这也很不方便，因为如果我们轮换一些密钥或秘密信息，就需要新的提交和审查阶段：如果部署不当，这个阶段可能会被阻止或拖延数小时乃至数天。而是应将所有此类数据存储在专门的服务中，根据需要注入所需的秘密信息或上下文变量。
在典型情况下，当基础架构计划创建、提交进行部署时，我们以AWS Secrets Manager或Vault为例来获取那些值。这可以借助适当的访问控制和审核，更安全地处理秘密信息。
2. 将状态文件提交到版本控件中
对于Terraform的用户而言，状态文件是启动IaC计划时创建的项目。它们含有用于特定基础架构的实用的元数据和配置选项。将敏感值存储在状态文件中，并提交到版本控制中的可能性比较大，这可以理解。别人试图从版本控制中检出代码时，这会带来其他问题。状态文件会过时或不完整。他们可能最终部署难以安全回滚的错误或不安全的基础架构组件。
共享和重用状态文件的最佳方法是在远程状态位置(通常是远程存储服务，比如AWS的S3)共享状态文件，并实施了适当的权限机制。
3.在部署前后未执行健全性和安全性检查
在使用模板或状态计划之前，您可以选择针对当前基础架构部署来进行验证。这将有助于发现任何语法错误;但最重要的是，有助于发现在此过程中可能添加的任何意想不到的破坏性变更。
另外，部署完毕之后，应该有另外的健全性和安全性检查，以回答最常见的问题：部署的基础架构是否安全?部署是否留下了敞开的端口?部署是否没有破坏未使用的资源?
第一步是在部署后编写验收测试以验证常见的安全假设(请参阅TaskCat和Terratest)。此外，应该有一个自动化系统(比如Prisma Cloud)，它可以对环境进行定期检查，以发现任何偏差，并上报安全问题。
4. 使用不受信任的图像或插件
如果旧的或来历不明的图像和实例有漏洞，使用这类图像和实例可能会带来安全风险。如果您使用来自第三方的IaC插件(比如，使用Terraform时通常会出现这种情况)，会发生同样的问题。就因为是开源公开的，并不意味着它们是可信任的可靠的。实际上，除非建立了全面的安全检查，否则它们会带来很大的安全风险，因为它们可能会在运行时泄漏数据或执行不安全的部署。
在实际使用之前，应对图像或插件的功能进行一番认真的同行审查和评估。
5. 不重用代码并将所有内容放在一个文件中
把所有配置和模板放在一个文件中会招惹灾难，这是由于它们可能不搭。增加配置数量可能导致大量重复代码。这种代码重复导致难以理解的模板，从而导致更多的配置漂移，最终可能出现在生产环境中。IaC模板应按环境和逻辑边界加以组织管理，比如生产环境、开发环境和模拟环境，它们有各自的数据库、VPC、权限和IAM策略模板。
每次使用通用引用和共享模块都有助于更有把握、更一致地部署基础架构资源。
结束语
您可以从上述场景中清楚地了解到IaC模板是源代码，需要将其视为源代码。这实际上意味着，将这些模板提交到版本控制系统中之前，应该每次都对这些模板进行多人审核、质量评估、格式化和验证。
应及早制定一些组织政策。只有这样，我们才能确保避免一大堆的错误以及任由未经检查的代码进入生产环境的风险。遵循良好的工程实践并密切关注始终有助于从源头避免这些风险。
原文标题：5 Common Risks in Infrastructure-as-Code Templates，作者：Theo Despoudis
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
