Terraform 的基础设施治理正在进入一个更贴近工程现场的阶段。HashiCorp 推出基于 HCL 的策略即代码框架 tfpolicy，目前以公开测试版形式集成在 HCP Terraform 中。它的核心方向很明确：让策略创建、检查和执行成为 Terraform 工作流的一部分，而不是依赖额外的工具链和另一套策略语言。
为什么策略治理需要更靠近 Terraform
在大型团队中，Terraform 配置负责描述资源，策略工具负责判断这些资源是否符合组织规则。两套系统可以协作，但也会带来额外成本：开发者需要学习不同的语言，平台团队需要维护独立的执行流程，策略失败时还要在 Terraform 计划与外部检查结果之间来回定位。
tfpolicy 试图缩短这条链路。策略使用 HCL 表达，并嵌入 HCP Terraform 的工作流中。这样，团队可以围绕同一套 Terraform 配置和执行过程完成基础设施变更与治理检查。
这种设计尤其适合以下规则：
- 资源必须使用组织认可的区域或账号。
- 公有网络入口需要经过明确审批。
- 存储资源必须启用加密。
- 生产环境的实例规格、标签或网络配置必须符合标准。
- Terraform 计划中的高风险变更需要被阻止或进一步审查。
策略即代码的价值不只是“发现违规”。更重要的是，它能把治理要求变成可版本控制、可评审、可重复执行的工程资产。
HCL 带来的实际变化
采用 HCL 编写策略，意味着 Terraform 使用者可以在熟悉的配置语言环境中理解治理规则。对于已经维护 Terraform module、变量和工作区的团队，这比引入完全不同的策略语言更容易形成统一的代码评审习惯。
一个成熟的策略工作流通常包含三个层次：
- 规则定义：明确哪些资源属性必须满足什么条件。
- 执行时机：在 Terraform plan 或工作区运行过程中检查策略。
- 处理结果：决定违规是直接阻止、提示风险，还是进入人工审批。
公开测试版意味着接口、语法和集成细节仍可能变化。实际落地时，不应把 beta 期间的示例直接当成长期稳定的兼容承诺，而应该把策略文件纳入版本控制，并在升级 tfpolicy 或 HCP Terraform 后重新验证。
一个可改造的策略仓库示例
下面是一个最小的项目布局示例。policies/ 中的具体规则语法需要以当前 tfpolicy beta 文档和工作区支持的 schema 为准；目录组织、评审方式和本地验证流程可以直接用于实践。
infrastructure/
├── main.tf
├── variables.tf
├── policies/
│ ├── required-tags.tfpolicy.hcl
│ └── approved-regions.tfpolicy.hcl
└── README.md
可以先用 Terraform 的常规命令确认基础设施配置本身没有问题：
#!/usr/bin/env bash
set -euo pipefail
terraform fmt -check -recursive
terraform init -backend=false
terraform validate
terraform plan -out=tfplan
策略文件可以围绕业务语言组织。例如，下面这段是一个示意规则，表达“资源区域必须来自允许列表”的意图。由于 tfpolicy 处于公开测试阶段，运行前请根据当前版本调整字段名和声明结构：
# policies/approved-regions.tfpolicy.hcl
# 示意：请按当前 tfpolicy beta schema 校正 rule/resource/query 等字段。
policy "approved_regions" {
description = "Production resources must use an approved region."
allowed_regions = [
"us-east-1",
"eu-west-1",
]
enforcement = "hard-mandatory"
}
更稳妥的实施方式是先从报告模式或非阻断模式开始，收集现有基础设施中的违规项，再逐步将关键规则提升为阻断策略。否则，一条未经清理的历史配置可能让所有新的 Terraform 运行都无法通过。
tfpolicy 与独立策略工具的取舍
把策略能力放进 Terraform 工作流，可以减少工具数量和上下文切换，但这并不代表所有治理需求都应该迁移到 tfpolicy。
适合优先放入 Terraform 策略层的规则，通常与资源计划直接相关，例如资源类型、属性、区域、标签、网络暴露面和变更风险。它们可以在基础设施变更发生时被及时判断。
而跨系统的安全合规、运行时行为、云账号状态或组织级审计，可能仍然需要云安全平台、合规扫描器或其他独立系统。策略边界应当清晰：Terraform 负责在交付路径上尽早阻止不合规变更，其他工具负责补充运行时和全局视角。
团队还需要关注几个风险：
- beta 稳定性：语法和集成能力可能继续演进。
- 误报与历史债务：过于严格的策略会阻塞正常交付。
- 策略权限：能够阻止生产变更的规则需要像应用代码一样经过评审。
- 反馈质量：策略失败信息必须指出资源、属性和修复方向，否则开发者只能反复试错。
落地清单
可以按下面的顺序引入：
- 选择一到两个高价值、低争议的规则，例如必需标签或允许区域。
- 将策略文件与 Terraform module 放入同一套代码评审流程。
- 先使用非阻断执行，统计违规来源和修复成本。
- 为生产工作区定义明确的阻断级别和例外流程。
- 在 HCP Terraform 的测试工作区验证策略失败时的提示、审批和回滚行为。
- 为 tfpolicy beta 版本锁定测试范围，并在平台升级后重新运行验证。
tfpolicy 的关键意义在于治理位置的变化：策略不再只是 Terraform 运行之后的旁路检查，而可以成为 Terraform 交付流程中的原生组成部分。对于已经使用 HCP Terraform 的团队，最现实的路径不是一次性重写所有合规规则，而是从少量可解释、可修复的规则开始，逐步建立以 HCL、版本控制和工作区执行为中心的治理习惯。