如何解決多租戶叢集的安全隔離問題是企業上雲的一個關鍵問題，本文主要介紹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級别的細粒度通路控制
- 使用安全容器實作容器運作時刻核心級别的安全隔離
- 完備的監控，日志，存儲等服務的多租隔離方案