Kubernetes多租戶集群實踐

如何解決多租戶集群的安全隔離問題是企業上雲的一個關鍵問題，本文主要介紹kubernetes多租戶集群的基本概念和常見應用形態，以及在企業內部共享集群的業務場景下，基於kubernetes原生和ACK集群現有安全管理能力快速實現多租戶集群的相關方案。

什么是多租戶集群？

這里首先介紹一下"租戶"，租戶的概念不止局限於集群的用戶，它可以包含為一組計算，網絡，存儲等資源組成的工作負載集合。而在多租戶集群中，需要在一個集群范圍內（未來可能會是多集群）對不同的租戶提供盡可能的安全隔離，以最大程度的避免惡意租戶對其他租戶的攻擊，同時需要保證租戶之間公平地分配共享集群資源。

在隔離的安全程度上，我們可以將其分為軟隔離(Soft Multi-tenancy)和硬隔離（Hard Multi-tenancy）兩種。其中軟隔離更多的是面向企業內部的多租需求，該形態下默認不存在惡意租戶，隔離的目的是為了內部團隊間的業務保護和對可能的安全攻擊進行防護；而硬隔離面向的更多是對外提供服務的服務供應商，由於該業務形態下無法保證不同租戶中業務使用者的安全背景，我們默認認為租戶之間以及租戶與k8s系統之間是存在互相攻擊的可能，因此這里也需要更嚴格的隔離作為安全保障。關於多租戶的不同應用場景，在下節會有更細致的介紹。

多租戶應用場景

下面介紹一下典型的兩種企業多租戶應用場景和不同的隔離需求：

1）企業內部共享集群的多租戶

該場景下集群的所有用戶均來自企業內部，這也是當前很多k8s集群客戶的使用模式，因為服務使用者身份的可控性，相對來說這種業務形態的安全風險是相對可控的，畢竟老板可以直接裁掉不懷好意的員工：）根據企業內部人員結構的復雜程度，我們可以通過命名空間對不同部門或團隊進行資源的邏輯隔離，同時定義以下幾種角色的業務人員：

• 集群管理員：

  • 具有集群的管理能力（擴縮容、添加節點等操作）
  • 負責為租戶管理員創建和分配命名空間
  • 負責各類策略（RAM/RBAC/networkpolicy/quota...）的CRUD

• 租戶管理員

  • 至少具有集群的RAM只讀權限
  • 管理租戶內相關人員的RBAC配置

• 租戶內用戶

  • 在租戶對應命名空間內使用權限范圍內的k8s資源

在建立了基於用戶角色的訪問控制基礎上，我們還需要保證命名空間之間的網絡隔離，在不同的命名空間之間只能夠允許白名單范圍內的跨租戶應用請求。

另外，對於業務安全等級要求較高的應用場景，我們需要限制應用容器的內核能力，可以配合seccomp/AppArmor/SELinux等策略工具達到限制容器運行時刻capabilities的目的。

當然Kubernetes現有的命名空間單層邏輯隔離還不足以滿足一部分大型企業應用復雜業務模型對隔離需求，我們可以關注Virtual Cluster，它通過抽象出更高級別的租戶資源模型來實現更精細化的多租管理，以此彌補原生命名空間能力上的不足。

2）SaaS & KaaS 服務模型下的多租戶

在SaaS多租場景下，kubernetes集群中的租戶對應為SaaS平台中各服務應用實例和SaaS自身控制平面，該場景下可以將平台各服務應用實例划分到彼此不同的命名空間中。而服務的最終用戶是無法與Kubernetes的控制平面組件進行交互，這些最終用戶能夠看到和使用的是SaaS自身控制台，他們通過上層定制化的SaaS控制平面使用服務或部署業務（如下左圖所示）。例如，某博客平台部署在多租戶集群上運行。在該場景下，租戶是每個客戶的博客實例和平台自己的控制平面。平台的控制平面和每個托管博客都將在不同的命名空間中運行。客戶將通過平台的界面來創建和刪除博客、更新博客軟件版本，但無法了解集群的運作方式。

​ KaaS多租場景常見於雲服務提供商，該場景下業務平台的服務直接通過Kubernetes控制平面暴露給不同租戶下的用戶，最終用戶可以使用k8s原生API或者服務提供商基於CRDs/controllers擴展出的接口。出於隔離的最基本需求，這里不同租戶也需要通過命名空間進行訪問上的邏輯隔離，同時保證不同租戶間網絡和資源配額上的隔離。

與企業內部共享集群不同，這里的最終用戶均來自非受信域，他們當中不可避免的存在惡意租戶在服務平台上執行惡意代碼，因此對於SaaS/KaaS服務模型下的多租戶集群，我們需要更高標准的安全隔離，而kubernetes現有原生能力還不足以滿足安全上的需求，為此我們需要如安全容器這樣在容器運行時刻內核級別的隔離來強化該業務形態下的租戶安全。

實施多租戶架構

在規划和實施多租戶集群時，我們首先可以利用的是Kubernetes自身的資源隔離層，包括集群本身，命名空間，節點，pod和容器均是不同層次的資源隔離模型。當不同租戶的應用負載能夠共享相同的資源模型時，就會存在彼此之間的安全隱患。為此，我們需要在實施多租時控制每個租戶能夠訪問到的資源域，同時在資源調度層面盡可能的保證處理敏感信息的容器運行在相對獨立的資源節點內；如果出於資源開銷的角度，當有來自不同租戶的負載共享同一個資源域時，可以通過運行時刻的安全和資源調度控制策略減少跨租戶攻擊的風險。

雖然Kubernetes現有安全和調度能力還不足以完全安全地實施多租隔離，但是在如企業內部共享集群這樣的應用場景下，通過命名空間完成租戶間資源域的隔離，同時通過RBAC、PodSecurityPolicy、NetworkPolicy等策略模型控制租戶對資源訪問范圍和能力的限制，以及現有資源調度能力的結合，已經可以提供相當的安全隔離能力。而對於SaaS、KaaS這樣的服務平台形態，我們可以通過容器服務八月即將推出的安全容器來實現容器內核級別的隔離，能夠最大程度的避免惡意租戶通過逃逸手段的跨租戶攻擊。

本節重點關注基於Kubernetes原生安全能力的多租戶實踐。

訪問控制

AuthN & AuthZ & Admission

ACK集群的授權分為RAM授權和RBAC授權兩個步驟，其中RAM授權作用於集群管理接口的訪問控制，包括對集群的CRUD權限（如集群可見性、擴縮容、添加節點等操作），而RBAC授權用於集群內部kubernetes資源模型的訪問控制，可以做到指定資源在命名空間粒度的細化授權。

ACK授權管理為租戶內用戶提供了不同級別的預置角色模板，同時支持綁定多個用戶自定義的集群角色，此外支持對批量用戶的授權。如需詳細了解ACK上集群相關訪問控制授權，請參閱相關幫助文檔。

NetworkPolicy

NetworkPolicy可以控制不同租戶業務pod之間的網絡流量，另外可以通過白名單的方式打開跨租戶之間的業務訪問限制。

您可以在使用了Terway網絡插件的容器服務集群上配置NetworkPolicy，這里可以獲得一些策略配置的示例。

PodSecurityPolicy

PSP是k8s原生的集群維度的資源模型，它可以在創建pod請求的admission階段校驗其行為是否滿足對應PSP策略的要求，比如檢查pod是否使用了host的（網絡，文件系統，指定端口，PID namespace）等，同時可以限制租戶內的用戶開啟特權（privileged）容器，限制掛盤類型，強制只讀掛載等能力；不僅如此，PSP還可以基於綁定的策略給pod添加對應的SecurityContext，包括容器運行時刻的uid，gid和添加或刪除的內核capabilities等多種設置。

關於如何開啟PSP admission和相關策略及權限綁定的使用，可以參閱這里

OPA

​ OPA（Open Policy Agent）是一種功能強大的策略引擎，支持解耦式的policy decisions服務並且社區已經有了相對成熟的與kubernetes的集成方案。當現有RBAC在命名空間粒度的隔離不能夠滿足企業應用復雜的安全需求時，可以通過OPA提供object模型級別的細粒度訪問策略控制。

同時OPA支持七層的NetworkPolicy策略定義及基於labels/annotation的跨命名空間訪問控制，可以作為k8s原生NetworkPolicy的有效增強。

資源調度相關

Resource Quotas & Limit Range

在多租戶場景下，不同團隊或部門共享集群資源，難免會有資源競爭的情況發生，為此我們需要對每個租戶的資源使用配額做出限制。其中ResourceQuota用於限制租戶對應命名空間下所有pod占用的總資源request和limit，LimitRange用來設置租戶對應命名空間中部署pod的默認資源request和limit值。另外我們還可以對租戶的存儲資源配額和對象數量配額進行限制。

關於資源配額的詳細指導可以參見這里

Pod Priority/Preemption

從1.14版本開始pod的優先級和搶占已經從beta成為穩定特性，其中pod priority標識了pod在pending狀態的調度隊列中等待的優先級；而當節點資源不足等原因造成高優先的pod無法被調度時，scheduler會嘗試驅逐低優先級的pod來保證高優先級pod可以被調度部署。

在多租戶場景下，可以通過優先級和搶占設置確保租戶內重要業務應用的可用性；同時pod priority可以和ResouceQuota配合使用，完成租戶在指定優先級下有多少配額的限制。

Dedicated Nodes

注意：惡意租戶可以規避由節點污點和容忍機制強制執行的策略。以下說明僅用於企業內部受信任租戶集群，或租戶無法直接訪問 Kubernetes 控制平面的集群。

通過對集群中的某些節點添加污點，可以將這些節點用於指定幾個租戶專門使用。在多租戶場景下，例如集群中的GPU節點可以通過污點的方式保留給業務應用中需要使用到GPU的服務團隊使用。集群管理員可以通過如effect: "NoSchedule"這樣的標簽給節點添加污點，同時只有配置了相應容忍設置的pod可以被調度到該節點上。

當然惡意租戶可以同樣通過給自身pod添加同樣的容忍配置來訪問該節點，因此僅使用節點污點和容忍機制還無法在非受信的多租集群上保證目標節點的獨占性。

關於如何使用節點污點機制來控制調度，請參閱這里。

敏感信息保護

secrets encryption at REST

在多租戶集群中不同租戶用戶共享同一套etcd存儲，在最終用戶可以訪問Kubernetes控制平面的場景下，我們需要保護secrets中的數據，避免在訪問控制策略配置不當情況下的敏感信息泄露。為此可以參考k8s原生的secret加密能力，請參閱這里。

ACK也提供了基於阿里雲KMS服務的secrets加密開源解決方案，可以參閱這里。

總結

​ 在實施多租戶架構時首先需要確定對應的應用場景，包括判斷租戶內用戶和應用負載的可信程度以及對應的安全隔離程度。在此基礎上以下幾點是安全隔離的基本需求：

• 開啟Kubernetes集群的默認安全配置

  • 開啟RBAC鑒權，禁止匿名用戶訪問
  • 開啟secrets encryption能力，增強敏感信息保護
  • 基於CIS kubernetes benchmarks進行相應的安全配置
• 開啟NodeRestriction， AlwaysPullImages, PodSecurityPolicy等相關admission controllers
• 通過PSP限制pod部署的特權模式，同時控制其運行時刻SecurityContext
• 配置NetworkPolicy
• Docker 運行時刻開啟Seccomp/AppArmor/SELinux配置
• 盡量實現監控、日志等服務的多租隔離

而對於如SaaS、KaaS等服務模型下，或者我們無法保證租戶內用戶的可信程度時，我們需要采取一些更強有力的隔離手段，比如：

• 使用如OPA等動態策略引擎進行網絡或Object級別的細粒度訪問控制
• 使用安全容器實現容器運行時刻內核級別的安全隔離
• 完備的監控，日志，存儲等服務的多租隔離方案

 

本文作者：dahukkk

原文鏈接

本文為阿里雲內容，未經允許不得轉載。