基础架构即代码模板的五个常见风险

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模板是源代码，需要将其视为源代码。这实际上意味着，将这些模板提交到版本控制系统中之前，应该每次都对这些模板进行多人审核、质量评估、格式化和验证。