为何Terraform不对敏感值进行哈希处理？

Terraform状态文件明文存储敏感值（哪怕标记了sensitive = true），核心原因不是技术上做不到哈希，而是哈希会破坏Terraform的核心工作流，具体来说有这几个关键点：

• Terraform需要原始敏感值完成资源生命周期管理
  很多云资源的创建、更新、销毁依赖敏感值的实际内容。比如创建RDS实例时要传入数据库密码，后续如果密码变更，Terraform需要对比新旧实际值来判断是否要触发资源更新。如果存哈希，Terraform拿不到原始值，根本没法完成这些核心操作。

• 哈希无法满足精确对比与回滚需求
  哈希只能检测值是否变化，但没法区分是真实变更还是极端情况下的哈希碰撞，更没法知道具体变更内容。另外，当需要回滚到之前的状态时，哈希无法还原原始敏感值，导致回滚操作失败——Terraform需要能恢复到之前的精确配置，哈希做不到这一点。

• 设计思路：把敏感值保护交给后端存储
  Terraform的设计理念里，状态文件本身的加密不是核心，而是推荐用户使用加密的状态后端来保护敏感数据。比如用Terraform Cloud的加密状态存储，或者AWS S3配合KMS服务器端加密、Azure Blob Storage的加密功能等。哈希是单向操作，无法还原原始值，而加密存储是双向的，只有持有密钥才能解密，既保护了数据安全，又不影响Terraform对原始值的需求。

• 向后兼容与生态成本
  Terraform早期版本就采用了明文存储状态的设计，后续添加sensitive标记只是在输出、日志中遮蔽敏感值，而非修改状态存储逻辑。如果改成哈希存储，大量依赖状态文件原始值的现有工具、脚本、工作流都会失效，迁移成本极高，不符合Terraform的兼容性原则。

内容的提问来源于stack exchange，提问作者Agyss