Kubernetes API 伺服器繞過風險
Kubernetes API 伺服器是外部各方（使用者和服務）與叢集互動的主要入口點。
作為此角色的一部分，API 伺服器具有幾個關鍵的內建安全控制措施，例如審計日誌和准入控制器。但是，存在繞過這些控制措施來修改叢集配置或內容的方法。
本頁面描述了繞過 Kubernetes API 伺服器內建安全控制措施的方法，以便叢集操作員和安全架構師可以確保這些繞過得到適當的限制。
靜態 Pod
每個節點上的kubelet 會載入並直接管理儲存在指定目錄中或從特定 URL 獲取的任何清單作為叢集中的_靜態 Pod_。API 伺服器不管理這些靜態 Pod。對該位置具有寫入訪問許可權的攻擊者可以修改從該源載入的靜態 Pod 的配置，或者可以引入新的靜態 Pod。
靜態 Pod 被限制訪問 Kubernetes API 中的其他物件。例如，您無法配置靜態 Pod 以從叢集中掛載 Secret。但是，這些 Pod 可以執行其他安全敏感操作，例如使用來自底層節點的`hostPath` 掛載。
預設情況下，kubelet 會建立一個映象 Pod，以便靜態 Pod 在 Kubernetes API 中可見。但是，如果攻擊者在建立 Pod 時使用無效的名稱空間名稱，它將不會在 Kubernetes API 中可見，並且只能透過有權訪問受影響主機（或多個主機）的工具來發現。
如果靜態 Pod 未透過准入控制，kubelet 將不會向 API 伺服器註冊該 Pod。但是，該 Pod 仍在該節點上執行。有關更多資訊，請參閱kubeadm issue #1541。
緩解措施
- 僅在節點需要時啟用 kubelet 靜態 Pod 清單功能。
- 如果節點使用靜態 Pod 功能，請將靜態 Pod 清單目錄或 URL 的檔案系統訪問許可權限制給需要訪問的使用者。
- 限制對 kubelet 配置引數和檔案的訪問，以防止攻擊者設定靜態 Pod 路徑或 URL。
- 定期審計和集中報告對託管靜態 Pod 清單和 kubelet 配置檔案的目錄或 Web 儲存位置的所有訪問。
kubelet API
kubelet 提供一個 HTTP API，該 API 通常在叢集工作節點上的 TCP 埠 10250 上公開。根據所使用的 Kubernetes 分發，該 API 也可能在控制平面節點上公開。直接訪問該 API 允許披露有關節點上執行的 Pod、這些 Pod 的日誌以及在節點上執行的每個容器中執行命令的資訊。
當 Kubernetes 叢集使用者對 `Node` 物件子資源具有 RBAC 訪問許可權時，該訪問許可權將用作與 kubelet API 互動的授權。確切的訪問許可權取決於已授予的子資源訪問許可權，如kubelet 授權中所述。
直接訪問 kubelet API 不受准入控制的約束，並且不會被 Kubernetes 審計日誌記錄。具有直接訪問此 API 許可權的攻擊者可能能夠繞過檢測或阻止某些操作的控制措施。
kubelet API 可以配置為以多種方式驗證請求。預設情況下，kubelet 配置允許匿名訪問。大多數 Kubernetes 提供商會將預設設定更改為使用 Webhook 和證書身份驗證。這使得控制平面能夠確保呼叫者被授權訪問 `nodes` API 資源或子資源。預設的匿名訪問不進行此斷言。
緩解措施
- 使用諸如RBAC 之類的機制限制對 `nodes` API 物件的子資源的訪問。僅在需要時（例如由監控服務）授予此訪問許可權。
- 限制對 kubelet 埠的訪問。只允許指定的受信任 IP 地址範圍訪問該埠。
- 確保kubelet 身份驗證設定為 Webhook 或證書模式。
- 確保叢集上未啟用未經驗證的“只讀”Kubelet 埠。
etcd API
Kubernetes 叢集使用 etcd 作為資料儲存。`etcd` 服務偵聽 TCP 埠 2379。唯一需要訪問的客戶端是 Kubernetes API 伺服器和您使用的任何備份工具。直接訪問此 API 允許披露或修改叢集中儲存的任何資料。
etcd API 的訪問通常由客戶端證書身份驗證管理。etcd 信任的證書頒發機構頒發的任何證書都允許完全訪問 etcd 中儲存的資料。
直接訪問 etcd 不受 Kubernetes 准入控制的約束，也不會被 Kubernetes 審計日誌記錄。對 API 伺服器的 etcd 客戶端證書私鑰具有讀取訪問許可權（或可以建立新的受信任客戶端證書）的攻擊者可以透過訪問叢集 Secret 或修改訪問規則來獲得叢集管理員許可權。即使沒有提升其 Kubernetes RBAC 許可權，能夠修改 etcd 的攻擊者也可以檢索任何 API 物件或在叢集內建立新的工作負載。
許多 Kubernetes 提供商將 etcd 配置為使用相互 TLS（客戶端和伺服器都驗證彼此的證書進行身份驗證）。儘管該功能存在，但 etcd API 的授權沒有被廣泛接受的實現。由於沒有授權模型，任何具有 etcd 客戶端訪問許可權的證書都可以用於完全訪問 etcd。通常，僅用於健康檢查的 etcd 客戶端證書也可以授予完全的讀寫訪問許可權。
緩解措施
- 確保 etcd 信任的證書頒發機構僅用於該服務的身份驗證。
- 控制對 etcd 伺服器證書的私鑰以及 API 伺服器的客戶端證書和金鑰的訪問。
- 考慮在網路級別限制對 etcd 埠的訪問，只允許來自指定和受信任 IP 地址範圍的訪問。
容器執行時套接字
在 Kubernetes 叢集中的每個節點上，與容器互動的訪問由容器執行時（如果您配置了多個執行時）控制。通常，容器執行時會公開一個 Unix 套接字，kubelet 可以訪問該套接字。對該套接字具有訪問許可權的攻擊者可以啟動新的容器或與正在執行的容器互動。
在叢集級別，此訪問的影響取決於執行在受感染節點上的容器是否可以訪問攻擊者可用於將許可權提升到其他工作節點或控制平面元件的 Secret 或其他機密資料。
緩解措施
- 確保您嚴格控制對容器執行時套接字的檔案系統訪問。如果可能，請將此訪問許可權限制為 `root` 使用者。
- 使用 Linux 核心名稱空間等機制將 kubelet 與節點上執行的其他元件隔離。
- 確保您限制或禁止使用包含容器執行時套接字的`hostPath` 掛載，無論是直接掛載還是透過掛載父目錄。此外，`hostPath` 掛載必須設定為只讀，以減輕攻擊者繞過目錄限制的風險。
- 限制使用者對節點的訪問，尤其是限制超級使用者對節點的訪問。