【Wiz 主動防禦】策略解析 Kubernetes 資料平面存取向量 第二部曲：補足防禦策略暴露攻擊面
- Estrella Wei
- 5月23日
- 讀畢需時 7 分鐘
已更新：9月22日
作者：Shay Berkovich ｜ 編譯：AIShield 編輯部 ｜ 發稿日期：2025 年 5 月 30 日
深入了解 Kubernetes 資料平面的存取方式，包含叢集內運行的應用程式、容器映像檔，以及執行即服務的工作負載類型。
這是我們兩篇部落格系列的第二部分，我們將深入探索進入 Kubernetes 環境的各種初始存取路徑，分析相關的攻擊面向，並釐清潛在的資安風險。
分類檢視
在第一篇部落格中，我們介紹了初始存取路徑的分類，並討論了控制平面（Control Plane）的存取。在這一部分，我們將著重於資料平面（Data Plane）的存取。我們會仔細檢視源自於叢集內應用程式的潛在初始存取路徑，討論容器映像檔（包含其來源與潛在的逃脫情境）的相關疑慮，最後再探討執行即服務（Execution-as-a-Service）的工作負載類型。
應用程式
Kubernetes 叢集天生就是為了運行各種工作負載（Workloads）而設計，而這些工作負載自然會透過執行業務邏輯來完成特定任務。每個工作負載都可能存在導致遠端程式碼執行（Remote Code Execution, RCE）的嚴重漏洞。要使這些漏洞能被利用，它必須對外開放且能被外部使用者存取——無論是直接（例如：前端 Pod 的 RCE），還是間接（例如：因錯誤配置導致 SQL 資料庫 Pod 的 RCE，透過前端 Pod 存取）。
由於應用程式安全已超出本文範疇，我們在此將重點放在初次存取後如何遏制攻擊者。在這種情境下，惡意行為者會發現自己處於易受攻擊 Pod 的執行環境中，如圖所示：
從這一點開始，攻擊者有兩個主要的路徑可以利用：
（1）濫用與此 Pod 服務帳戶（Service Account, SA）相關的 Kubernetes RBAC 權限；
（2）濫用當前容器或相鄰 Pod 容器內的系統權限，以逃逸至主機（escape to the host）並進行橫向移動（lateral movement）。
多種資安防線（Security Boundaries）旨在防範這些橫向移動和權限提升的情境，例如 Kubernetes 命名空間（Namespace）（RBAC 分離）、Pod 安全標準（Pod Security Standards, PSS）（限制 Pod 系統功能）、網路策略（Network Policies）以及專用的 Kubernetes 節點排程（Node Scheduling）。攻擊者的成功與否，取決於這些安全控制措施的有效性。在我們的 2023 年 Kubernetes 安全報告中，我們強調了一旦攻擊者獲得初始存取後，橫向移動的機會隨處可見。Wiz 漏洞研究團隊發現了涉及 Kubernetes 基礎設施的一系列資安漏洞，正說明了這一點。
我們強烈建議在叢集內部混合運用各種資安防線，尤其要做到：
將前端與對外服務的 Pod 分離到不同的命名空間，並賦予其服務帳戶最小權限。
在命名空間層級，為您的工作負載套用適當的 Pod 安全標準 (PSS) 等級。如有需要，可根據敏感度級別劃分命名空間。
在管理 Pod 中的漏洞時，優先處理那些公開曝露且具有強大權限的 Pod。
若需更嚴格的硬體多租戶（hard multi-tenancy），請考慮使用獨立的 K8s 叢集。詳情請參閱 PEACH 雲端隔離框架。
NodePort 服務
Kubernetes 提供多種方式將工作負載曝露給外部使用者，其中負載平衡器服務（Load Balancer Services）和應用程式閘道器（Application Gateways）是最常見的。另一種較不常見的 Pod 曝露方式是透過 NodePort 服務。當叢集操作員建立 NodePort 服務時，Kubernetes 會在工作節點上，於預設的 30000–32767 範圍內開啟一個靜態埠號。
NodePort 服務存在多個資安疑慮，主要是因為它「通常不應用於生產系統」。因此，它的存在可能意味著服務意外曝露。即使工作負載並不存在，叢集中的所有節點都會開啟相同的埠號，不必要地增加了曝露面。每個節點都會將埠號代理到服務，使得直接存取成為可能。與負載平衡器服務相比，細粒度的網路存取控制也更為有限。我們對 100 個使用 Kubernetes 的 Wiz 客戶隨機抽樣分析顯示，約有 6% 的客戶將 NodePort 服務對外曝露。
映像檔與供應鏈
容器映像檔（Container Images）提供了一個較不明顯，但仍具風險的存取途徑。如果攻擊者控制了一個映像檔，而叢集中的 Pod 又拉取了這個映像檔，那麼從容器執行到本地節點管理員（local node admin）——甚至可能到叢集管理員（cluster admin）——的路徑可能很短。去年冬天揭露的 Leaky Vessels 漏洞，正是其中一個凸顯不可信映像檔風險的惡名昭彰案例。runc 程式庫中的漏洞，僅需部署一個惡意映像檔的 Pod，就能造成未經授權的主機層級存取。
為了降低這些風險：
為資料平面工作負載套用適當的 PSS 等級，以防止容器逃逸。
將命名空間作為橫向移動的資安防線，限制 RBAC 權限僅限於命名空間範圍。
考慮對不需要特殊條件的 Pod 使用使用者命名空間（User Namespaces），如同我們之前的研究所示。這個進階功能使得主機環境中的 root 權限失效。
同樣重要的是，映像檔是少數無法透過網路限制來緩解的向量之一，因為 Pod 需要從容器 Registry 下載映像檔。惡意映像檔凸顯了擁有高品質軟體以及與受信任夥伴建立強健的保管鏈（Chain of Custody）（包含 SBOM 和簽章）的重要性。這強調了在使用容器映像檔之前進行驗證的重要性。兩種映像檔安全策略是：
維護一個本地（鏡像）容器 Registry，並進行漏洞與出處檢查。
透過 Admission Controller (AC) 邏輯實作映像檔簽章驗證，確保只部署已簽署、受信任的映像檔。
Wiz 最近讓確保 Kubernetes 叢集中的軟體供應鏈安全變得極為容易。傳統上驗證映像檔的方式是透過數位簽章建立映像檔信任。這確保了部署的映像檔來自受信任的來源（在部署時使用公鑰驗證已簽署的映像檔）。
Wiz 透過 Wiz Image Trust 將其提升到新的水準，它不僅能讓您建立信任，還能將資安政策與每個部署的映像檔緊密綁定，從而確保映像檔符合組織的資安合規性：在映像檔被拉取之前和任何時間點，掃描 CVEs、惡意軟體和嵌入式機密——輕鬆回溯到與部署映像檔相關的 CI/CD 掃描和掃描政策。這一切都不需要處理金鑰管理，而金鑰管理通常是簽署和驗證映像檔時最具挑戰性的操作環節之一。
執行即服務 (Execution-as-a-Service)
一個經常被低估的初始存取路徑是執行即服務，其中服務供應商向服務使用者提供執行功能。例如，運行外部 AI 模型的能力，等同於執行任意程式碼。由於 Kubernetes 是一個非常方便的技術，AI 供應商越來越多地利用 K8s Pod 和容器來運行模型。因此，供應商必須依賴 K8s 的安全隔離控制措施，而正如我們之前所見，這些措施很難正確實作。
Wiz 漏洞研究團隊在多個 AI 服務中發現了跨租戶漏洞，例如 HuggingFace Inference API、Replicate 和 SAP AI Core。這些研究文章說明了這類服務相關的主要風險——跨租戶存取。下圖顯示了典型的攻擊流程：
此外，這種攻擊流程可以廣義地影響任何依賴 Kubernetes 叢集作為後端的執行即服務基礎設施。提供此類服務的供應商必須對執行環境實施嚴格的資安控制措施。以下是需要考慮的關鍵措施：
每個執行 Pod 一個命名空間（可行時）：將每個 Pod 隔離到自己的命名空間有助於遏制潛在的漏洞，並限制攻擊面。
執行 Pod 的使用者命名空間：這項進階功能可防止容器的根權限轉換為主機層級的根存取，增加一層額外的安全性。
網路安全策略：實施細粒度的網路策略可限制 Pod 到 Pod 的通訊，降低工作負載之間橫向移動的可能性。
每個租戶一個節點排程：為不同的租戶分配個別的工作節點可確保隔離，並防止共享基礎設施環境中的跨租戶威脅。
核心隔離與沙箱技術（例如：Kata Containers、gVisor、seccomp、AppArmor）：使用額外的核心層級隔離和沙箱技術可顯著降低容器逃逸的風險，並增強系統層級的安全性。
最後，取決於這些控制措施的實施效果，考慮改用獨立的虛擬機器 (VM)，而非僅依賴 Kubernetes 叢集，以實現更強大的隔離。
雲端存取與 CI/CD
由於篇幅限制，我們無法在本文中涵蓋雲端存取和 CI/CD 管道這些廣泛的主題，但它們在 Kubernetes 安全中是關鍵領域。我們的 2023 年 Kubernetes 安全報告強調，絕大多數叢集（超過 80%）都是在雲端管理和運行，使其成為更廣泛雲端基礎設施不可或缺的一部分。這意味著叢集操作員必須具備雲端 IAM (Identity and Access Management) 的能見度，才能有效管理大規模的叢集存取。
雲端 IAM 是一個動態且複雜的領域，新功能不斷推出。我們預計會有更多權限提升漏洞從這個領域產生，類似於我們在本系列前面詳細介紹的漏洞。掌握這些發展對於領先於新興風險至關重要。
CI/CD 管道，作為現代軟體開發流程的核心，是 Kubernetes 安全的另一個重要向量。Kubernetes 整合到 CI/CD 工具鏈中，例如 ArgoCD 和 Flux 等操作器，會自動化新舊叢集中的 K8s 資源部署。這些工具簡化了操作，但也代表著嚴重的資安隱憂，因為 CI/CD 工作流程通常擁有 Kubernetes 環境的管理員級別存取權限，這可能為攻擊者提供一個在叢集中獲得初始立足點的路徑。
結論
這篇部落格是我們 Kubernetes 初始存取兩部曲的完結篇（請參閱第一部）。如前所述，Kubernetes 是一個複雜、分散式的系統，具有多個存取途徑，其中任何一個如果沒有妥善保護，都可能導致整個叢集被攻陷。我們希望這份分類能幫助您系統化並優先處理相關風險。
本文翻譯自 Wiz 原文：“ Making Sense of Kubernetes Initial Access Vectors Part 2 - Data Plane ”
發佈日期：2024 年 11 月 13 日
原文連結：Wiz 部落格文章
