對於許多使用 GitOps 的工程師來說，Argo CD 已經是部署 Kubernetes 應用程式的標準工具。然而，隨著企業對安全要求的提高，單純將設定檔放在 Git 就不夠了，我們必須思考：如果內部通訊被監聽怎麼辦？如果 Git 倉庫被駭客篡改了怎麼辦？
Argo CD 3.5 版本針對這些「供應鏈安全」的痛點推出了幾項關鍵更新，特別是在內部 mTLS 加密、來源完整性驗證以及管理可視化方面。
內部通訊的漏洞與 mTLS 的引入
在先前的版本中，Argo CD 的內部組件（例如 API Server、Controller 與 Repo-server）之間的通訊大多是未加密的。雖然大多數團隊會在 Ingress 層（外部進入集群的入口）設定 TLS 加密，但一旦流量進入集群內部，組件之間的 gRPC 通訊就處於裸奔狀態。如果攻擊者成功滲透進集群內部，就有機會監聽或攔截這些敏感的內部流量。
為了修復這個漏洞，Argo CD 3.5 引入了強制性的 mTLS（Mutual TLS，雙向傳輸層安全協定）。mTLS 與一般我們在瀏覽器看到的 TLS 不同，它要求通訊的雙方都必須提供憑證來證明自己的身份，確保只有經過授權的內部組件能互相交談。
對於沒有自備憑證管理系統的團隊，Repo-server 現在支援在記憶體中自動產生自簽名憑證，這樣既能滿足健康檢查的需求，又不需要依賴檔案系統，提升了部署的靈活性與安全性。
防止惡意代碼潛入：來源完整性驗證
GitOps 的核心是 Git 作為唯一真理來源，但這也帶來一個風險：如果 Git 倉庫被攻破，攻擊者可以直接修改 Manifests（設定檔），而 Argo CD 會忠實地將這些惡意變更同步到集群中。
為了防止這種情況，Argo CD 3.5 推出了 Source Integrity（來源完整性）驗證。這項功能允許管理員強制要求 Git commit 必須經過數位簽章（Signature Verification）。當此功能開啟時，Argo CD 在同步前會檢查提交記錄是否具有有效的簽章，若發現未簽名或簽章失效的變更，將拒絕同步。
工程師可以透過 Application 的設定檔將 sourceIntegrity.required 設為 true，或是使用 CLI 指令來啟用。這將安全性從單純的「權限控制」提升到了「內容驗證」的層級。
提升維運效率：ApplicationSet UI 與預覽功能
ApplicationSet 是一個強大的功能，允許我們用一套模板在多個集群或命名空間中大量產生應用程式。但過去 ApplicationSet 缺乏原生 UI 支援，工程師必須盯著 YAML 檔或使用 kubectl 來推測這套模板最終會產生哪些 App，這在大型環境中極其容易出錯。
新版本新增了專屬的 ApplicationSet UI，提供列表、篩選與詳細視圖。最重要的是它加入了 Preview Apps（應用程式預覽）分頁，讓維運人員在正式部署前，就能直觀地看到模板會生成哪些具體的應用程式，大幅降低了誤刪或誤建的風險。
其他重要功能更新
除了安全與 UI，3.5 版本還將兩項重要功能從 Alpha 提升至 Beta 階段：
第一是 Impersonation（身分模擬）。這允許 Argo CD 在執行伺服器端任務（如刪除資源或同步）時，採取特定使用者的身分。這對於多租戶（Multi-tenant）集群至關重要，因為它能讓稽核日誌（Audit Trail）清楚記錄到底是誰觸發了操作，而非全部顯示為系統帳號。
第二是 Source Hydrator（來源注水器）。這解決了 GitOps 中常見的乾濕分離問題。乾源（Dry Source）是包含模板的原始設定，濕源（Hydrated Source）則是渲染後的最終結果。現在團隊可以將這兩者放在不同的 Git 倉庫中，分別設定不同的存取權限，實現更精細的權限管理。
此外，此版本還增加了對 Helm 4 的支援，並允許 ApplicationSet 部署在任意命名空間中，不再侷限於 Argo CD 所在的命名空間。
技術對比：Argo CD vs Flux vs Fleet
面對相同的安全挑戰，不同工具採取了不同路徑。Flux 因為設計上是透過 Kubernetes API 物件進行非同步通訊，而非直接使用 gRPC，因此天生不需要內部 mTLS。而在 commit 簽章驗證上，Flux 較早提供 GPG 支援，Argo CD 此次更新可視為在功能面上的追趕。
Rancher Fleet 則採用 WebSocket Agent 機制，同樣避開了內部 mTLS 的需求，但在來源完整性驗證上較為薄弱，通常需要依賴 Git 供應商或外部的 Admission Webhook 來達成。
總結來說，Argo CD 3.5 的更新方向非常明確：將安全邊界從外部 Ingress 延伸到內部組件，並將信任鏈從單純的 Git 權限擴展到 Commit 簽章，同時透過 UI 降低大規模管理的複雜度。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。