本篇文章已發布超過一年。較舊的文章可能包含過時的內容。請確認頁面上的資訊自發布以來是否已變得不正確。
保護許可控制器
許可控制是 Kubernetes 安全性的重要組成部分，與身份驗證和授權並列。Webhook 許可控制器被廣泛使用，以多種方式協助提高 Kubernetes 叢集的安全性，包括限制工作負載的權限，以及確保部署到叢集的映像符合組織的安全要求。
然而，與添加到叢集的任何其他組件一樣，安全風險可能會隨之而來。一個安全風險的例子是，如果許可控制器的部署和管理未正確處理。為了幫助許可控制器使用者和設計者適當地管理這些風險，SIG Security 的 安全文件子組花費了一些時間開發了 許可控制器的威脅模型。此威脅模型著眼於因不正確使用許可控制器而可能產生的潛在風險，這些風險可能導致安全策略被繞過，甚至可能使攻擊者獲得對叢集的未經授權訪問權限。
從威脅模型中，我們制定了一套安全最佳實務，應加以採納以確保叢集運營商能夠獲得許可控制器的安全優勢，同時避免使用它們帶來的任何風險。
許可控制器和安全良好實務
從威脅模型中，浮現了關於如何確保許可控制器安全的幾個主題。
安全的 webhook 組態
重要的是要確保叢集中的任何安全組件都經過良好配置，許可控制器在此方面也不例外。使用許可控制器時，有幾個安全最佳實務需要考慮
- 為所有 webhook 流量正確配置 TLS。API 伺服器和許可控制器 webhook 之間的通訊應經過身份驗證和加密，以確保可能處於網路位置以查看或修改此流量的攻擊者無法做到這一點。為了實現此訪問，API 伺服器和 webhook 必須使用來自受信任憑證授權單位的憑證，以便它們可以驗證彼此的身份
- 僅允許經過身份驗證的訪問。如果攻擊者可以向許可控制器發送大量請求，他們可能能夠壓垮服務，導致其故障。確保所有訪問都需要強身份驗證應可減輕該風險。
- 許可控制器故障關閉。這是一種具有權衡的安全實務，因此叢集運營商是否要配置它將取決於叢集的威脅模型。如果許可控制器故障關閉，當 API 伺服器無法從其獲得回應時，所有部署都將失敗。這可以阻止攻擊者通過禁用許可控制器來繞過它，但是，可能會中斷叢集的運行。由於叢集可以有多個 webhook，因此一種折衷方法可能是將關鍵控制設置為故障關閉，而允許不太關鍵的控制故障開啟。
- 定期審查 webhook 組態。組態錯誤可能會導致安全問題，因此檢查許可控制器 webhook 組態以確保設置正確非常重要。這種審查可以通過基礎設施即代碼掃描器自動完成，也可以由管理員手動完成。
用於許可控制的安全叢集組態
在大多數情況下，叢集使用的許可控制器 webhook 將作為叢集中的工作負載安裝。因此，重要的是要確保可能影響其運行的 Kubernetes 安全功能已得到良好配置。
- 限制 RBAC 權限。任何擁有權限的使用者，如果這些權限允許他們修改 webhook 物件或許可控制器使用的工作負載的組態，都可能中斷其運行。因此，重要的是要確保只有叢集管理員才擁有這些權限。
- 防止特權工作負載。容器系統的現實之一是，如果給予工作負載某些特權，則可能會突破到基礎叢集節點並影響該節點上的其他容器。在許可控制器服務在其保護的叢集中運行的地方，重要的是要確保對特權工作負載的任何需求都經過仔細審查並盡可能地受到限制。
- 嚴格控制外部系統訪問。作為叢集中的安全服務，許可控制器系統將有權訪問敏感信息，例如憑證。為了降低此信息被發送到叢集外部的風險，應使用 網路政策 來限制許可控制器服務對外部網路的訪問。
- 每個叢集都有專用的 webhook。雖然可能有許可控制器 webhook 為多個叢集提供服務，但使用該模型存在風險，即對 webhook 服務的攻擊會在共享時產生更大的影響。此外，當多個叢集使用許可控制器時，複雜性和訪問要求將會增加，從而使其更難以保護。
許可控制器規則
用於 Kubernetes 安全性的任何許可控制器的關鍵要素是其使用的規則庫。規則需要能夠準確地實現其目標，避免誤報和漏報結果。
- 定期測試和審查規則。需要測試許可控制器規則以確保其準確性。它們還需要定期審查，因為 Kubernetes API 會隨著每個新版本而更改，並且需要在每個 Kubernetes 版本發布時評估規則，以了解可能需要進行的任何更改以使其保持最新。