在現代的雲端基礎設施管理中，我們經常提到 IaC (Infrastructure as Code，基礎設施即代碼)，讓開發者可以用程式碼來定義伺服器或資料庫。但隨著公司規模擴大，不能讓每個人隨意建立任何資源，例如：禁止建立昂貴的 GPU 實例、規定所有儲存桶必須開啟加密，或者限制只能使用公司認可的模組。這就是 Policy as Code (政策即代碼) 要解決的問題，它將治理規則轉化為代碼，讓自動化檢查取代人工審核。
過去，HashiCorp 提供的是 Sentinel，而業界則流行使用 OPA (Open Policy Agent)。雖然這兩者很強大，但對工程師來說有個痛點：你需要學習一套全新的語言（如 Sentinel 語言或 Rego），且這些工具通常像是一個獨立的檢查層，與 Terraform 的主流程有一定的脫節。
為了簡化這個過程，HashiCorp 推出了 tfpolicy。這是一個基於 HCL (HashiCorp Configuration Language) 的新框架，讓你在定義基礎設施的同時，可以用同樣的語言來定義治理政策。
統一語言降低學習成本
tfpolicy 最核心的改變是將政策語言統一為 HCL。對於習慣使用 Terraform 的工程師來說，不再需要為了寫一條安全規則而切換到另一種語言。這種深度的整合意味著政策定義可以與基礎設施代碼共存於相同的開發工作流中，大幅降低了維護成本。
從單一資源檢查到關聯性治理
傳統的政策檢查通常只看單一資源的屬性，例如檢查某個 S3 桶是否公開。但現實中的基礎設施複雜度很高，很多問題出在資源之間的關聯。tfpolicy 引入了對資源關係的評估能力，並允許透過 Data Source (數據源) 查找外部上下文。這意味著政策可以根據整個系統的狀態，而非僅僅是單一資源的設定來判定是否合規。
全生命週期的治理能力
tfpolicy 將治理範圍擴展到了部署的前、中、後三個階段。
首先是在 Plan 階段，在資源實際建立前就攔截違規操作。其次是在部署過程中，控制 Provider (提供者) 與 Module (模組) 的下載，防止工程師意外使用未經審核的第三方套件，從而降低供應鏈風險。最後是部署後的評估，這點非常重要，因為有些違規情況只有在資源真正被佈署並產生實際狀態後才會顯現。
HCP Terraform 與 CLI 的差異
需要注意的是，tfpolicy 的完整能力僅在 HCP Terraform (HashiCorp 的託管平台) 中提供。在 HCP 環境中，它能與端到端的自動化流程深度整合，實現強制執行與自動化攔截。而獨立的 CLI 版本則主要定位於開發階段的本地測試與驗證，無法提供完整的自動化治理能力。
未來展望與遷移
雖然 HashiCorp 仍會支持 Sentinel，但 tfpolicy 已被定位為優先推薦的框架。為了幫助團隊遷移，官方還推出了 AI 代理工具，能夠自動生成 tfpolicy 配置、進行測試，甚至將舊有的 Sentinel 政策轉換為新的 HCL 格式。
總結來說，tfpolicy 的出現是將治理從外部的檢查層，轉化為基礎設施生命週期的一部分。它將安全與合規的門檻降低，讓平台團隊能用更自然的方式地確保雲端環境的安全性。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。