【Wiz 主動防禦】策略解析 Kubernetes 控制平面存取向量第一部曲：識別風險強化安全基石

Estrella Wei
5月23日
讀畢需時 6 分鐘

已更新：9月22日

作者：Shay Berkovich ｜編譯：AIShield 編輯部｜發稿日期：2025 年 5 月 29 日

深入探討 Kubernetes 控制平面的存取途徑、潛在風險，以及如何制定資安策略，有效防範未經授權的存取，保護您的叢集免受潛在威脅。

動機

Kubernetes (K8s) 是一個複雜的分布式系統，旨在以可擴展且易於管理的方式運行容器化工作負載。如今，它已成為雲原生環境中部署工作負載的預設方法。由於其靈活性和可擴展性，Kubernetes 在處理各種工作負載（例如：批次處理、高效能運算 HPC、GPU 運算）方面表現出色，這也促成了它的廣泛應用。

然而，隨著這個生態系統的快速演進，Kubernetes 的資安防護也必須跟上腳步。Kubernetes 常見的威脅類型包括加密貨幣挖礦、資源劫持、資料竊取、雲端跳板攻擊、IP 竊取等等。但這些攻擊都基於一個共同的前提：成功取得初始存取權限。

另一個比較不明顯的動機是：我們的《2023 年 Kubernetes 資安報告》顯示，一旦攻擊者取得初始存取權限，他們在叢集內部進行橫向移動和權限提升的機會就大增。這使得確保初始存取的安全性變得更加關鍵。

因此，瞭解您的叢集潛在存取向量，並知道如何偵測初始攻擊，是至關重要的。有興趣嗎？請繼續往下閱讀。

分類

目前 Kubernetes 初始存取的系統化實務仍有不足。像 MITRE Containers Matrix 和 Microsoft Threat Matrix for Kubernetes 等框架列出了一些初始存取技術，但並沒有深入分析或優先級排序。在這個部落格系列中，我們將介紹一個初始存取向量的分類法。

主要支柱代表四個主要的存取領域：控制平面 (Control Plane)、資料平面 (Data Plane)、雲端存取 (Cloud Access) 和 CI/CD。其中，雲端存取和 CI/CD 超出本文討論範圍；這裡我們將專注於 Kubernetes 本身。這些領域又進一步細分為更小的向量，並列出每個向量最主要的相關風險。舉例來說，設定錯誤是導致 Kubelet API 存取暴露的主要風險。接下來，我們將聚焦於控制平面存取，詳細拆解初始存取向量、相關風險，以及建議的防護與偵測技術。在下一篇文章中，我們將深入探討資料平面存取。

Kubernetes API 存取

K8s API 伺服器不僅是控制平面元件之間的通訊樞紐，它也是外部使用者與叢集互動的前端。這使得它成為存取和管理 K8s 叢集的主要方式。

未經驗證的存取

K8s API 的存取透過角色型存取控制 (RBAC) 進行管理。這裡的關鍵概念是使用者角色。預設情況下，K8s 會將每個未經驗證的使用者對應到 system:anonymous 角色，該角色屬於 system:unauthenticated 群組。當此功能被停用時（例如在 AKS 中），未經驗證的使用者在嘗試存取 API 端點時會收到 401 錯誤。當啟用時（例如在 EKS 和 GKE 中），未經驗證的使用者將被授予匿名角色的基本權限，例如檢索版本和健康狀況資訊：

然而，這也為潛在的 RBAC 設定錯誤開啟了大門。例如，一個懶惰的叢集管理員可能因為開發團隊需要存取權限卻沒有適當的憑證，而暫時賦予 system:unauthenticated 群組過高的權限。未經驗證的存取已經導致了多起資安事件。

Kubeconfig

kubeconfig 檔案定義了 kubectl 如何對 API 伺服器進行驗證。它包含三個主要部分：叢集（cluster IP 和憑證授權）、使用者（驗證資料）和上下文（叢集/使用者對）。建議將 kubeconfig 檔案視為包含機密資訊的檔案，特別是使用者部分，因為它包含驗證資料。


apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tL...
    server: IP
  name: cluster1
- cluster:
...
contexts:
- context:
    cluster: cluster1
    user: user1
  name: context1
- context:
...
kind: Config
preferences: {}
users:
- name: user1
  user:
- name: user2
  user:
- name: user3

在 EKS 和 GKE 中，這些是運行本地 kubectl exec 外掛程式（aws cli、aws-iam-authenticator、gke-gcloud-auth-plugin.exe）的指令，它們會獲取必要的雲端憑證，這樣憑證就不會儲存在 kubeconfig 檔案中。這有兩個優點：(1) 降低檔案暴露的風險；(2) 將驗證/授權移動到身分識別領域，這更易於稽核、偵測威脅等。然而在 AKS 中，驗證資料取決於叢集的驗證/授權方法。當創建新的 AKS 叢集時，使用者必須選擇方法，預設選項是「本機帳戶與 Kubernetes RBAC」：

預設情況下，AKS 的 Kubeconfig 檔案包含一個使用者令牌和客戶端憑證資料，可用於成功驗證。如果憑證在兩年內沒有輪替，惡意行為者可能會對叢集進行長期存取。

注意： 當然，雲端憑證外洩本身對 K8s 環境構成了非常嚴重的風險，無論雲端類型如何。然而，這超出本文的討論範圍，在上面的矩陣中被概括為「雲端存取」。

此風險也適用於自建叢集，它們提供了更廣泛的驗證選項（例如：作為令牌檔案、SSH 憑證、特殊命令等）。無論設定如何，請務必將您的 Kubeconfig 檔案視為敏感文件。切勿將其簽入公共儲存庫，這仍然是憑證外洩最常見的方式之一。簡單的 GitHub 搜尋就能以純文字形式揭露存取憑證：

Kubectl proxy

Kubectl proxy 是一種較不為人知的 K8s API 伺服器存取方式，通常用於臨時診斷或除錯。執行 kubectl proxy –port=8080 會在 localhost 和 K8s API 伺服器之間建立一個臨時代理伺服器。任何對 localhost:8080 的 API 呼叫都將作為 HTTP 請求執行，並由運行該命令的使用者授權。如果攻擊者能夠本地或透過網路（甚至是 SSRF）存取原始站點（開發人員筆記型電腦或跳板 VM），他們就可以利用這種未經驗證的連線：

幸運的是，這並不是一種常見的設定錯誤。Shodan 報告顯示，傳回狀態碼 200 並帶有相關 Kubernetes 標頭的端點不到 100 個：

圖 6：Shodan 關於 HTTP K8s API 端點的結果 — **圖片出自：Wix**

Kubelet API 存取

Kubelet 是運行在每個工作節點上的叢集控制平面代理程式，預設情況下，它只能由同一節點上的內部元件存取。然而，為了除錯目的，Kubelet API 可以對外暴露。此設定由儲存 kubelet 配置的 .conf 檔案中的 --anonymous-auth 和 --authorization-mode 參數控制。最糟糕的設定錯誤之一是節點上同時存在 --anonymous-auth=True / --authorization-mode=AlwaysAllow 組合，這會導致 Kubelet API 開放匿名存取。透過 Kubelet API 進行的初始存取將不會顯示在 K8s 稽核日誌中，需要感測器或 VPC 流量日誌才能偵測到此類活動。這是 TeamTNT 曾經鎖定的設定錯誤之一，但目前在生產系統中已不常見，通常與蜜罐叢集相關。

管理介面

Kubernetes Dashboard、Kubeflow、Argo Workflows 等管理介面提供了額外的叢集存取途徑。典型的設定錯誤是將儀表板保持未驗證狀態並暴露在公共網路上。這裡的風險取決於儀表板的功能和權限。

這些設定錯誤在幾年前更為常見，當時的預設設定不夠安全（最臭名昭著的入侵案例仍然是 2017 年 Tesla 儀表板的暴露事件）。如今，儀表板必須明確安裝，並預設啟用驗證。例如，Shodan 報告約有 4,000 個暴露的 Kubernetes 儀表板。然而，預設安裝模式需要驗證，因此期望輕鬆入侵的攻擊者將會面對登入畫面：

**圖片出自：Wix**，**圖 7：預設 Kubernetes 儀表板畫面**

總結：透過控制平面存取 Kubernetes

Kubernetes 是一個複雜的分布式系統，具有多個存取向量。每個向量如果沒有妥善保護，都可能導致整個叢集被入侵。在本文中，我們分享了控制平面 Kubernetes 初始存取向量的分類法，旨在協助營運人員和資安專業人士更好地保護他們的叢集。我們也針對每個向量概述了偵測和預防策略。

我們力求在涵蓋範圍上達到深度與廣度的平衡。在下一篇文章中，我們將針對資料平面存取向量進行同樣的探討。

本文翻譯自 Wiz 原文：“ Making Sense of Kubernetes Initial Access Vectors Part 1 – Control Plane ”

發佈日期：2024 年 11 月 12 日

原文出處：Wiz 部落格文章

👉 下一篇：【Wiz 主動防禦】策略解析 Kubernetes 資料平面存取向量第二部曲：補足防禦策略暴露攻擊面