IaC身份管理:標籤化解決雲端安全所有權挑戰
IaC 所有權:基於標籤的方法來管理雲基礎設施中的非人類身份

在迅速演變的雲基礎設施環境中,確定非人類身份(NHI)的所有權已成為一項關鍵的安全挑戰,尤其是在雲採用率以空前速度加速的亞太地區。當組織面臨 NHI 相關的安全事件時,能快速辨識負責的人員可以大大加快修復速度。雖然透過事件日誌跟蹤直接創建的雲身份的所有權相對簡單,但由基礎設施即代碼(IaC)生成的身份則帶來了更複雜的挑戰。
IaC 身份所有權的挑戰
基礎設施即代碼革新了組織部署雲資源的方式。DevOps 團隊僅需一個命令,即可在多個雲環境中創建數以百計的帳戶、服務器、政策和身份。這種高效性伴隨著一個重大的安全挑戰:確定誰實際上對這些程序化創建的身份負責。
考慮這種情境:開發人員通過 Terraform 部署請求一個新的 AWS IAM 角色。執行後,該角色由 Terraform 服務帳戶創建。如果我們查看雲日誌,該服務帳戶似乎是創建者——但是這無法告訴我們,如果角色出現問題應聯繫哪位人員。是執行部署的 DevOps 工程師?請求它的開發人員?還是設計創建它的模塊的架構師?
在現代 CI/CD 環境中,當部署由代碼提交自動觸發時,這個問題變得更加複雜:

在這些情況下,身份的創建甚至進一步與直接的人類行為脫鉤。CI/CD 管道無論何時有變更提交到存儲庫時,會自動執行 IaC 代碼。那麼結果身份的所有權屬於誰?配置管道的 DevOps 工程師?提交觸發代碼的開發人員?
當涉及模塊化的 IaC 組件時,情況變得更加複雜:

模塊是 IaC 中用來防止代碼重複的可重用模板。如果開發人員使用附加過權限政策到角色的模塊,誰該負責?實施模塊的開發人員?還是編寫它的工程師?
理解 IaC 資源創建過程
為了解決這個所有權挑戰,我們需要了解 IaC 如何在不同平台和服務中創建資源:

該圖展示了從代碼提交到實際雲資源的旅程。在 IaC 環境中,代碼本身是身份的一個組成部分。編寫新角色聲明性代碼的人,實質上是該身份的創造者。
這表明了一種簡單的方法來確定所有權:識別是誰編寫或提交了創建每個身份的代碼。這需要:
- 對每個 IaC 生成的身份,找出創建它的具體代碼
- 識別提交或編輯該代碼的人
雖然第二步比較簡單—大多數代碼存儲庫保持詳盡的提交歷史記錄—但第一步存在重大挑戰。IaC 項目通常有複雜的結構,其中數據流經多個文件、模塊和變數定義,最終創建雲資源。
基於標籤的 IaC 所有權解決方案
在探索解決這個問題的各種方法後,包括日誌分析和代碼解析,我們的研究開發了一種基於標籤的解決方案來跟蹤 IaC 身份所有權。此方法專注於利用 Terraform 自身的功能來跟蹤資源創建。
核心思想極為簡單:使用 Terraform 自身來記錄哪些代碼文件負責創建每個身份。這是通過以下方式完成的:
- 修改 IaC 代碼以向身份資源添加標籤
- 運行計划執行以產生每個資源的詳細信息
- 分析生成的計划以將身份映射到其源文件
步驟 1:準備環境
首先的挑戰是運行 Terraform 過程,而不影響實際的雲環境。Terraform 配置通常會與若干外部服務交互:
- 目標雲提供商(用於狀態管理和執行)
- Git 存儲庫(用于模塊和源代碼)
為了避免未預期的交互,我們對配置進行了修改,以便本地運行:
- 使用本地狀態管理代替遠程狀態(如 S3 存儲)
- 僅運行規劃操作(不修改環境)
- 本地克隆模塊而非從遠程存儲庫提取
在這些修改後,我們成功在沒有任何互聯網連接的情況下,對實際存儲庫執行 Terraform 計划命令,確保不會对實際環境進行任何更改。
步驟 2:用來源信息標籤資源
下一步是修改 IaC 代碼以跟蹤哪些文件為每個身份的創建做出貢獻。我們使用大多數雲平台支持的資源標籤功能完成了這一目標。
我們開發了一個腳本,該腳本掃描存儲庫並向每個相關文件添加信息標籤,包括:
- 包含 IAM 資源(用戶、角色、服務帳戶等)的文件
- 定義 IAM 資源的模塊文件
- 提供身份創建參數的輸入文件
運行時,該腳本向每個資源添加“來源路徑”標籤,允許我們跟蹤哪些文件參與了其創建。
步驟 3:生成增強的計畫文件
在運行標記代碼的 Terraform 計划後,結果是一個詳細的計划文件,包含每個身份的來源信息。以下是該文件的示例:
{ "address": "module.single_role['danz'].aws_iam_role.role", "mode": "managed", "type": "aws_iam_role", "name": "role", "provider_name": "registry.terraform.io/hashicorp/aws", "schema_version": 0, "values": { "description": "Just an AWS role", "name": "danz-role", "path": "/", "tags": { "ModuleFilePath": "/Users/danz/modules_repo/single_role/single_role.tf", "ResourceFilePath": "/Users/danz/modules_repo/resources/single_role/main.tf", "InputFilePath": "/Users/danz/infra_repo/src/us-east-1/my_env/roles/danz.json" } } }
這個增強的計畫文件顯示“danz-role”是通過以下方式創建的:
- 在“single_role.tf”中定義的模塊
- 在“main.tf”中詳細描述的資源
- 來自“danz.json”的輸入值
通過將這些文件與存儲庫提交歷史記錄相關聯,我們現在可以確定創建每個身份的人員。
挑戰和限制
雖然這種方法提供了有價值的見解,但也揭示了在大規模部署時限制其實用性的重大挑戰:
1. Terraform 計畫執行
運行不會影響目標環境的 Terraform 計划操作的難度超出了預期:
- 不同的雲提供商在計劃期間對遠程服務的依賴程度不同
- 雖然 AWS 允許相對容易的本地執行,但 Azure 需要更複雜的解決方案
- 某些資源類型需要模擬環境才能正確執行計劃
2. 代碼修改的複雜性
在各種 IaC 實施中,自動標記資源的過程充滿挑戰:
- 不同的文件格式和結構需要專門的解析
- 現有的 HashiCorp 配置語言(HCL)的解析器具有有限的編輯能力
- 實施的多樣性削弱了創建通用解決方案的目標
3. 標籤繼承問題
確保標籤在整個 Terraform 流程中正確傳遞並不容易:
- 許多模塊的設計不具備從輸入傳遞標籤到輸出的功能
- 復雜的資源鏈需要在每一步進行修改以維護標籤繼承
- 這些修改為解決方案增添了另一層複雜性
對 DevOps 團隊的實際應用
儘管面臨這些挑戰,基於標籤的方法為尋求改善其 IaC 身份管理的 DevOps 團隊提供了寶貴的見解:
- 增強的可視性:標籤提供了清晰的可視性,顯示出哪些代碼檔案負責創建每一個身份
- 簡化的故障排除:當身份問題出現時,了解源文件可加快問題解決
- 所有權追踪:對於擁有穩定 IaC 實施的組織,這種方法可以將身份映射到人類擁有者
擁有完整控制權的 IaC 存儲庫的 DevOps 團隊可能會發現此方法特別有價值,因為他們可以實施與其特定工作流程對應的標籤實踐。
針對非技術干系人的 IaC 所有權理解
對於不太熟悉基礎設施即代碼和身份管理的人群,這是此問題為何重要的簡化解釋:
想像一家擁有大型辦公樓的公司。在傳統 IT 中,如果有人需要某個安全區域的新門禁卡,過程很明確:一名員工請求訪問,安全經理批准,設施團隊創建並發放門禁卡。如果安全問題發生,很容易確定誰批准了訪問、誰應負責。
現在想像一個現代化的自動化建築,當有人修改建築數字設計時,門會自動創建新門禁卡。如果發生安全事件,追踪誰負責變得更加困難。是設計圖的架構師?編寫自動化代碼的程序員?還是請求更改的員工?
這基本上就是基於 IaC 創建的雲端身份的挑戰。當雲資源通過代碼自動創建時,確定人類責任變得複雜。然而,這一明確性對於安全性、合規性和事件應對至關重要。
我們探索的基於標籤的方法就像是為每張門禁卡添加了一個特殊的簽名,記錄了誰設計了它、誰編寫了程序,以及誰請求了它—這使得在需要時更容易確定責任。
結論
基礎設施即代碼極大地改善了雲資源管理,但也為身份所有權和安全性帶來了新的挑戰。我們對 IaC 身份所有權的標籤方法探索揭示了既有前景的能力,也有顯著的限制。
儘管該方法對於在多樣化環境中的通用實施來說過於複雜,但它為尋求改善其 IaC 身份管理實踐的組織提供了寶貴的見解。DevOps 團隊可以將這些概念適應到其特定環境,執行有針對性的標籤策略,以提高可見性和所有權跟踪。
隨著雲基礎設施的複雜性不斷增加,尤其是在多雲和混合部署日益普遍的亞太地區,解決身份所有權問題將始終是關鍵的安全挑戰。通過理解 IaC 代碼與其創建的身份之間的關係,組織可以為其雲環境開發更有效的安全和治理策略。
本文中詳細的研究旅程是 Token Security's 廣泛努力的一部分,旨在繪製出所有非人類身份及其在人類複雜環境中的擁有者。隨著組織數字化轉型旅程的不斷推進,對所有身份(人類和非人類)保持明確的可見性和責任將是維護在越來越自動化世界中安全性和合規性的關鍵。
留言
張貼留言