本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
保護准入控制器
准入控制與身份認證和授權一起，是 Kubernetes 安全的關鍵部分。Webhook 准入控制器被廣泛用於以各種方式幫助提高 Kubernetes 叢集的安全性，包括限制工作負載的許可權，以及確保部署到叢集的映象滿足組織的安全要求。
然而，與新增到叢集中的任何其他元件一樣，安全風險也可能出現。一個安全風險的例子是，如果准入控制器的部署和管理處理不當。為了幫助准入控制器使用者和設計者適當地管理這些風險，SIG Security 的安全文件子小組花了一些時間為准入控制器建立威脅模型。這個威脅模型著眼於因不正確使用准入控制器而可能出現的風險，這可能導致安全策略被繞過，甚至允許攻擊者獲得對叢集的未授權訪問。
根據威脅模型，我們制定了一套安全最佳實踐，應該採用這些實踐來確保叢集運營者能夠獲得准入控制器的安全優勢，同時避免使用它們帶來的任何風險。
准入控制器和安全最佳實踐
從威脅模型中，出現了幾個關於如何確保准入控制器安全性的主題。
安全的 Webhook 配置
確保叢集中的任何安全元件都配置良好是非常重要的，准入控制器在這裡也不例外。在使用准入控制器時，需要考慮幾個安全最佳實踐。
- 為所有 webhook 流量正確配置 TLS。API 伺服器和准入控制器 webhook 之間的通訊應該進行身份驗證和加密，以確保可能處於網路位置檢視或修改此流量的攻擊者無法這樣做。為了實現這一點，API 伺服器和 webhook 必須使用來自受信任證書頒發機構的證書，以便它們可以驗證彼此的身份。
- 只允許經過身份驗證的訪問。如果攻擊者可以向准入控制器傳送大量請求，他們可能會使服務不堪重負，導致其失敗。確保所有訪問都需要強身份驗證應該可以降低這種風險。
- 准入控制器失敗關閉（Fail-closed）。這是一個有權衡的安全實踐，因此叢集運營者是否希望配置它將取決於叢集的威脅模型。如果一個准入控制器失敗關閉，當 API 伺服器無法從它那裡得到響應時，所有部署都將失敗。這可以阻止攻擊者透過停用它來繞過准入控制器，但是，可能會中斷叢集的執行。由於叢集可以有多個 webhook，一種折中的方法可能是將關鍵控制設定為失敗關閉，而不太關鍵的控制允許失敗開放（Fail-open）。
- 定期審查 webhook 配置。配置錯誤可能導致安全問題，因此檢查准入控制器 webhook 配置以確保設定正確非常重要。這種審查可以透過基礎架構即程式碼（Infrastructure As Code）掃描器自動完成，也可以由管理員手動完成。
安全的叢集准入控制配置
在大多數情況下，叢集使用的准入控制器 webhook 將作為叢集中的工作負載安裝。因此，確保可能影響其操作的 Kubernetes 安全功能配置良好非常重要。
- 限制 RBAC 許可權。任何擁有允許修改 webhook 物件配置或准入控制器使用的工作負載許可權的使用者都可能破壞其操作。因此，確保只有叢集管理員擁有這些許可權非常重要。
- 防止特權工作負載。容器系統的一個現實是，如果一個工作負載被賦予了某些特權，它將有可能突破到底層的叢集節點，並影響該節點上的其他容器。當準入控制器服務執行在它們所保護的叢集中時，確保任何對特權工作負載的需求都經過仔細審查並儘可能地加以限制是非常重要的。
- 嚴格控制對外部系統的訪問。作為叢集中的安全服務，准入控制器系統將能夠訪問像憑據這樣的敏感資訊。為了降低這些資訊被髮送到叢集外部的風險，應該使用網路策略來限制准入控制器服務對外部網路的訪問。
- 每個叢集都有一個專用的 webhook。雖然可能存在服務於多個叢集的准入控制器 webhook，但使用這種模型存在一個風險，即對 webhook 服務的攻擊在共享時會產生更大的影響。此外，當多個叢集使用一個准入控制器時，複雜性和訪問要求會增加，使其更難保護。
准入控制器規則
任何用於 Kubernetes 安全的准入控制器的一個關鍵元素是它使用的規則庫。規則需要能夠準確地滿足其目標，避免誤報和漏報。
- 定期測試和審查規則。准入控制器規則需要進行測試以確保其準確性。它們還需要定期審查，因為 Kubernetes API 會隨著每個新版本而變化，並且每個 Kubernetes 版本釋出時都需要評估規則，以瞭解可能需要進行的任何更改以保持其最新狀態。