在現代雲端基礎設施管理中，基礎設施即程式碼（Infrastructure as Code, IaC）已成為標準做法。Pinterest 使用 Terraform 作為其主要的 IaC 工具，用以管理包含 IAM 政策、VPC 虛擬私有雲、負載平衡器、S3 儲存桶以及 Kubernetes 叢集在內的數千個 AWS 資源。然而，當公司規模擴大後，基礎設施的定義分散在眾多不同的儲存庫（Repositories）中，且由不同團隊各自維護。這種多儲存庫的架構帶來了一個嚴重的安全挑戰：如果 CI/CD 系統（持續整合與持續部署）被授予足以跨多個儲存庫與 AWS 帳號進行變更的廣泛權限，一旦發生配置錯誤或遭到惡意攻擊，將會產生巨大的風險。
為了在尚未完成儲存庫整合（Mono-repo）之前解決這個問題，Pinterest 開發了一套名為 Resource Provisioner Pipeline（RPP）的集中式 Terraform 執行引擎。RPP 的核心目標是在 GitHub Actions 的工作流程中加入嚴格的護欄（Guardrails），確保所有基礎設施的變更都遵循最小權限原則（Least-privilege access），並在執行前經過雙重控制審核。
RPP 的運作方式將執行邏輯從各個獨立儲存庫的腳本中抽離，轉而採用集中式的複合 GitHub Actions（Composite GitHub Actions）。當開發者提交 Pull Request（PR）時，RPP 會被觸發，並將單一 PR 拆分為針對每個受影響工作空間（Workspace）的獨立計畫（Plan）與執行（Apply）階段。
其安全機制採用了鏈式角色模型（Chained-role model）。首先，工作流程會獲取一個中央角色 RPPActionsRole，此角色僅限於通過 OIDC（OpenID Connect，一種用於身分驗證的開放標準）令牌驗證的授權工作流程使用。接著，系統會讀取一份權威配置檔案（Source-of-truth configuration file），該檔案定義了每個工作空間對應的允許儲存庫、工作目錄、擁有團隊以及執行所需的 IAM 角色。
在正式切換到具體權限之前，RPP 會執行關鍵的驗證步驟：檢查 Terraform 程式碼路徑是否與該工作空間對應的 S3 後端（Backend）及 KMS 金鑰（Key Management Service，用於加密管理）一致。這一點至關重要，因為它能防止開發者不小心將某個工作空間的目錄連結到另一個工作空間的狀態檔案（State file），避免發生跨空間的狀態損壞。驗證通過後，管線才會切換到該團隊特定的受限角色，執行格式化（fmt）、計畫（plan），並在獲得人類審核者明確評論後，才執行套用（apply）。
這種集中式管理模式為 Pinterest 帶來了顯著的維運效益。由於執行邏輯統一，當基礎設施出現系統性問題（例如 CI 執行環境的 Shell 漏洞）時，工程師只需在一個地方進行修復，而不需要修改數百個儲存庫。此外，集中化也讓團隊能一致地導入靜態分析工具（如 Semgrep）與 AI 輔助掃描，甚至在影響真實帳號前，利用 LocalStack（一個模擬 AWS 環境的工具）進行模擬執行（Dry run）。
從實務意義來看，RPP 實踐了兩層雙重控制：一是程式碼層級的審核批准，二是觸發 Apply 動作前必須有明確的 PR 評論。這將計畫與執行完全分離，確保每一步變更都可被稽核。
將 RPP 與其他大型企業的作法相比，可以發現不同的策略選擇。例如 Mercari 曾面臨類似問題，他們透過 GCP 的工具將權限拆分為唯讀的 Plan 帳號與特定服務的 Apply 帳號，利用 impersonation（身分模擬）來限制影響範圍。Slack 則採取去中心化路徑，將狀態所有權交還給各團隊，但仍維持嚴格的 Sandbox 到 Production 的階段閘門。
RPP 的獨特之處在於其強大的後端與 KMS 金鑰驗證機制。它在假設任何角色之前，先驗證路徑與狀態檔案的對應關係，為集中式 IaC 管線增加了一道防線，防止其成為單一故障點（Single Point of Failure）。對於目前處於多儲存庫狀態且無法立即遷移至單一儲存庫的團隊而言，這種透過權威配置、後端驗證與權限降級（Down-scoping）的模式，提供了一個兼顧開發效率與雲端安全的參考架構。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。