Terraform 与 OpenTofu 基础及状态安全
Terraform 与 OpenTofu 通过声明式配置管理基础设施。计划文件显示“准备做什么”，状态文件记录“配置对象与真实资源如何对应”。状态不是普通缓存，其中可能包含地址、标识和敏感值，必须按机密数据管理。
一、标准工作流
tofu fmt -check -recursive
tofu init
tofu validate
tofu plan -out=change.tfplan
tofu show change.tfplan
tofu apply change.tfplan
也可将 tofu 替换为对应 Terraform 命令。生产中应将“生成计划”和“审批后应用”分开，确保应用的是已审阅的计划，而不是重新计算出的未知变更。
二、状态为什么重要
状态负责保存资源绑定、依赖和元数据。直接编辑 JSON 很危险，应使用 state、import、moved 等受支持能力。删除配置不等于只从管理中移除资源，计划中可能出现真实删除操作。
状态文件可能包含标记为敏感的输入和输出。sensitive 主要减少终端显示，不代表状态中不保存明文。
三、生产状态基线
- 使用支持访问控制、版本、加密和状态锁的远程后端。
- 按环境和故障域分离状态，避免一个状态控制过多无关资源。
- 限制
state pull、state push和强制解锁权限。 - 对后端、加密密钥和状态版本做备份及恢复演练。
- CI 运行身份使用短期凭据，不把云密钥写入变量文件。
- 本地残留的计划、崩溃日志和状态备份也要清理和保护。
OpenTofu 支持状态与计划静态加密，但丢失密钥会导致无法读取；启用前应演练迁移和密钥恢复。
四、模块与版本
模块应有明确输入、输出、版本和责任边界。Provider 与模块版本要固定在可控范围，并提交锁文件。升级前阅读变更说明，在测试环境重新生成计划。
不要把环境差异堆进大量条件表达式。若权限、生命周期和责任人不同，应考虑拆分模块或状态。
五、导入已有资源
导入只建立状态绑定，不会自动生成完整、正确的配置。导入后必须：
- 补齐与真实资源一致的配置；
- 执行计划并确认没有意外替换或删除；
- 识别由外部系统继续管理的字段；
- 决定是否使用忽略变更，并记录原因；
- 通过小范围资源验证再批量导入。
六、漂移与紧急变更
定期只读运行计划可发现漂移。紧急情况下若必须在控制台手工修改，事后应立即把变更回写到代码或明确撤销，不要让手工状态长期存在。
七、高风险操作保护
- 审查
destroy、replace和批量变更数量。 - 对数据库、磁盘、IP、域名等关键资源设置适当生命周期保护。
- 计划中出现未知值时确认其影响，不能只看总数。
- 手工
state push -force风险极高，执行前拉取备份并核对 lineage、serial 和目标后端。 - 删除或重建前确认数据备份、复制和业务回退。
八、验收清单
- 配置格式、静态校验和计划审查通过；
- 远程状态启用权限控制、锁、版本和加密；
- 无明文密钥提交，运行身份可追溯；
- 应用后的二次计划没有意外差异；
- 状态、密钥和关键数据有可验证恢复方案；
- 资源标签、负责人、环境和成本归属完整。