K8s准入控制與RBAC比較

banq發表於2021-06-12
K8S

今天，如果你正在執行Kubernetes，你知道，安全是不是“內建”。為了確保您的叢集，您必須在額外的控制配置，新增或建立。有些是Kubernetes的一部分，是基於角色的訪問控制（RBAC），但其他的最佳實踐包括指定受信任的儲存庫已知良好的容器中，然後在執行時掃描工具層次感為好。
但現實是，在Kubernetes，你可以做所有這些事情“正確的”，但一切仍可能會出錯。您RBAC控制元件可以是有一定作用，你只能使用可靠且簽名的Image，使用者可以無盡掃描你的容器中 ，你的叢集會斷裂或破壞。換句話說，即使是乾淨且可信的Image，如果部署不正確，也會導致叢集配置錯誤——從而導致返工、停機或（更糟糕的）資料丟失的風險。
然而，Kubernetes 的一個美妙之處在於它提供了一種優雅的控制來防止正確的事物以錯誤的方式行事。Kubernetes准入控制（admission control）允許開發者直接在其叢集上執行安全策略，以管理和控制什麼可以為了被部署到極限的危險，並防止以往出現的許多安全問題。
。例如，此類策略可能會阻止軟體以 root 身份執行，防止來自 Web 的有害入侵，或確保新部署的容器無法從現有的暴露於 Internet 的工作負載中竊取流量——所有潛在的安全問題，如 RBAC 或執行時安全性工具無法解釋。事實上，准入控制不僅功能強大而且正迅速成為確保Kubernetes的強制性工具。
 

RBAC的侷限性
要理解為什麼開發人員需要准入控制，讓我們先來看看RBAC的侷限性，值得信賴的儲存庫和執行時工具。這需要我們來看看這些工具的源：發展預雲時代。在傳統的IT安全模式，核心因素，開發商對其進行評價：

  • 身份與網路 - 誰可以訪問什麼？
  • 已知的漏洞 - 這已知漏洞可以在我們的環境中執行？

在 Kubernetes 中，這些概念非常接近於 RBAC 和容器中的程式碼掃描；在執行之前和執行期間。很自然，具有安全意識的團隊會採用這些工具作為保護叢集的第一道防線。但在完全由軟體定義的環境中，藉助 Kubernetes 允許的精細控制，傳統方法本身在這些雲原生環境中不可避免地存在差距。
以RBAC為例。RBAC 控制誰或什麼可以將程式碼放入您的叢集；通常，這些許可權是透過 CI/CD 管道自動化的。理論上，這意味著只有受信任的參與者才能將受信任或批准的Image映象放入您的叢集。但是，透過 CI/CD 流程大規模自動化的人為錯誤會帶來大規模問題。而且，由於Kubernetes API是基於意圖和要求YAML的任意塊的檢查，RBAC實際上提供遠低於在Kubernetes比其他系統的控制。   
可信庫，同時，保證映象永不來自未知或不可信來源。它們包含已批准的映象，通常帶有已掃描漏洞的程式碼。然而，正如我們將看到的，即使是可信的映象也可能以錯誤的方式部署。
 最後，執行時工具允許您監控部署的環境。這些工具有助於檢測異常活動、監控容器之間以及外部客戶端和服務之間的通訊，以及發現新發現的漏洞。儘管如此，您的執行時環境可以完全乾淨、無漏洞，並且仍然會遭到破壞。
在實踐中，傳統工具無法解決天生的雲問題。例如，即使是一個乾淨且可信的映象，如果部署不正確，也可能被惡意行為者用來橫向移動到其他容器。或者，它可以簡單地以不應該的方式與網際網路交談。這些“乾淨的形象，糟糕的結果”的情況是多種多樣的：
由正確的管道部署並持續掃描的乾淨映象可以：
  • 允許意外從網際網路出口；
  • 無意中擴充套件以捕獲 CPU 資源並使其他程式崩潰；
  • 以特權執行，使其成為可妥協的、支援橫向移動的風險；
  • 與其名稱空間外的容器“對話”並放置資料和風險；
  • 命名為“latest”，防止叢集回滾；
  • 還有很多很多。

Kubernetes 准入控制提供了一種方法來阻止這些不想要的場景中的每一個——您需要做的就是定義允許正確的規則，停止不正確的規則。更具體地說，您可以使用准入控制器來防止錯誤配置導致問題。這是因為準入控制器是“有目的的瓶頸”，可讓您攔截對 Kube API 的請求並對其實施安全策略，然後再將它們作為物件部署到 Kubernetes 中。
 

由 Kubernetes 准入控制賦予的權力
我們從開發人員社群聽到了很多關於 Kubernetes 准入控制的訊息，因為我們的開源策略引擎Open Policy Agent (OPA)出人意料地最受歡迎的用例之一就是作為 Kubernetes 准入控制器。OPA 非常適合准入控制，因為它允許您將企業安全策略（通常儲存在 wiki、PDF 或人們的頭腦中）轉換為策略即程式碼，並透過准入控制 Webhook 直接在叢集上實施它們。  
無論您選擇哪種控制器（即使它只是自定義程式碼），准入控制都可用於防止各種 Kubernetes 錯誤配置。例如，您可以建立策略以：

  • 防止容器以 root 身份執行（只能以“非 root”身份執行）；
  • 僅部署標記為釋出的映象；
  • 確保正確的標籤/標籤；
  • 僅公開某些 IP 和埠；
  • 僅掛載允許的檔案系統。

同樣重要的是，您還可以為容器周圍的配置實施策略。例如，您可以控制以下因素：  
  • 自動複製。
  • 阻止公眾進入。
  • 安全。
  • 最低可靠性（例如，要求您執行三個副本）。

然而，在准入控制的世界中，可能性（或限制）是無窮無盡的：您可以為在 Kubernetes 上執行的任何軟體的配置編寫策略。關鍵在於，使用 Kubernetes 准入控制，您可以實施基本上保證安全性、合規性和操作安全性的護欄——透過在錯誤配置發生之前防止它們。    

相關文章