這篇文章要討論的是一個針對 Argo CD 的嚴重安全漏洞。對於初入行的工程師來說，首先要理解 Argo CD 的運作邏輯。Argo CD 是一個實現 GitOps 的工具，它會監控 Git 儲存庫中的設定檔，並將其同步到 Kubernetes 集群中。在這個過程中，有一個關鍵組件叫做 Repo-Server，它的工作是讀取 Git 內容並將其轉換為 Kubernetes 能夠理解的 Manifests（定義資源如何部署的 YAML 檔案）。
漏洞核心：Repo-Server 的未授權執行風險
安全研究公司 Synacktiv 發現，Argo CD 的 Repo-Server 組件中存在一個嚴重的缺陷。簡單來說，Repo-Server 內部使用 gRPC 協議進行通訊，但這個內部服務竟然沒有設定身分驗證機制。這意味著只要攻擊者能夠接觸到這個組件的網路連接埠，就可以直接向它發送請求。
攻擊者利用了 Kustomize 的特性來達成目的。Kustomize 是 Argo CD 用來處理設定檔的標準工具，它有一個參數叫 helm-command，原本是用來指定要呼叫哪個 Helm 二進位檔。攻擊者可以透過發送一個偽造的 GenerateManifest 請求，將這個參數修改為一個惡意的腳本路徑。當 Repo-Server 執行 Kustomize 時，它不會執行真正的 Helm，而是會執行攻擊者準備好的惡意腳本，從而導致遠端程式碼執行（RCE）。
內部網路不等於安全：Network Policy 的缺失
很多工程師會認為內部服務不需要驗證，因為它在集群內部，外部進不來。但這正是最危險的假設。在 Kubernetes 中，如果沒有設定 Network Policy（網路策略，一種用來控制 Pod 之間通訊權限的防火牆規則），預設情況下集群內的所有 Pod 都可以互相溝通。
最糟糕的是，許多人使用 Helm Chart 安裝 Argo CD，而該 Chart 的預設設定中，networkPolicy.create 是關閉的（false）。這意味著如果攻擊者只要攻破集群中任何一個微小的、權限很低的 Pod，就可以直接橫向移動，接觸到 Repo-Server 並觸發上述漏洞。
從 RCE 到集群接管的連鎖反應
拿到 Repo-Server 的執行權限後，攻擊者並未停止。他們發現可以從環境變數中讀取 Redis 的密碼。Redis 在 Argo CD 中被用作快取來儲存部署數據。
一旦拿到 Redis 密碼，攻擊者就可以對快取內容進行污染（Poisoning）。當 Argo CD 下一次自動執行同步（Sync）時，它會讀取被篡改的快取數據，進而將攻擊者指定的惡意工作負載部署到集群中。這種攻擊路徑實際上讓之前的 CVE-2024-31989 漏洞死灰復燃，證明了僅僅加上密碼而沒有對快取內容進行數位簽章（Signing）是不夠的。
目前的應對方案與實務建議
目前這個漏洞尚未有官方補丁（Patch），因此唯一的防禦手段是實施嚴格的網路隔離。
工程師應立即檢查集群中的網路策略。請執行 kubectl get networkpolicy -A 指令。在健康的安裝環境中，每個組件（包括 Repo-Server 和 Redis）都應該有對應的網路策略，限制僅允許 Argo CD 自身的組件相互存取。如果發現沒有相關策略，請立即將其開啟。
總結來說，這次事件提醒我們兩個重要的安全原則：第一，絕對不要信任內部網路，必須實施零信任架構；第二，對於擁有集群高權限的工具（如 Argo CD），其內部的每個組件都應該被視為高風險目標，必須透過網路層級的強隔離來降低風險。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。