作者 | 匡大虎  阿里巴巴技術專家

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

# 什麼是多租戶叢集？

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

在隔離的安全程度上，我們可以將其分為軟隔離 (Soft Multi-tenancy) 和硬隔離 (Hard Multi-tenancy) 兩種。

- 其中軟隔離更多的是面向企業內部的多租需求，該形態下預設不存在惡意租戶，隔離的目的是為了內部團隊間的業務保護和對可能的安全攻擊進行防護；
- 而硬隔離面向的更多是對外提供服務的服務供應商，由於該業務形態下無法保證不同租戶中業務使用者的安全背景，我們預設認為租戶之間以及租戶與 K8s 系統之間是存在互相攻擊的可能，因此這裡也需要更嚴格的隔離作為安全保障。

關於多租戶的不同應用場景，在下節會有更細緻的介紹。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/1052193e3ac04b059aeedc4e2fe68c48.png)

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

## 企業內部共享叢集的多租戶

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

- 叢集管理員：具有叢集的管理能力（擴縮容、新增節點等操作）；負責為租戶管理員建立和分配名稱空間；負責各類策略（RAM/RBAC/networkpolicy/quota...）的 CRUD；
- 租戶管理員：至少具有叢集的 RAM 只讀許可權；管理租戶內相關人員的 RBAC 配置；
- 租戶內使用者：在租戶對應名稱空間內使用許可權範圍內的 K8s 資源。

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

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

![3.png](https://ucc.alicdn.com/pic/developer-ecology/8fa8664cb1314a4abb89f10f32310717.png)

當然 Kubernetes 現有的名稱空間單層邏輯隔離還不足以滿足一部分大型企業應用複雜業務模型對隔離需求，我們可以關注 [Virtual Cluster](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RseBCBhb5u_g6iwpVABP--XHhKi6I9-i_UTB8QJrT9k%2Fedit)，它透過抽象出更高階別的租戶資源模型來實現更精細化的多租管理，以此彌補原生名稱空間能力上的不足。

## SaaS & KaaS 服務模型下的多租戶
在 SaaS 多租場景下， Kubernetes 叢集中的租戶對應為 SaaS 平臺中各服務應用例項和 SaaS 自身控制平面，該場景下可以將平臺各服務應用例項劃分到彼此不同的名稱空間中。而服務的終端使用者是無法與 Kubernetes 的控制平面元件進行互動，這些終端使用者能夠看到和使用的是 SaaS 自身控制檯，他們透過上層定製化的 SaaS 控制平面使用服務或部署業務（如下左圖所示）。

例如，某部落格平臺部署在多租戶叢集上執行。在該場景下，租戶是每個客戶的部落格例項和平臺自己的控制平面。平臺的控制平面和每個託管部落格都將在不同的名稱空間中執行。客戶將透過平臺的介面來建立和刪除部落格、更新部落格軟體版本，但無法瞭解叢集的運作方式。

KaaS 多租場景常見於雲服務提供商，該場景下業務平臺的服務直接透過 Kubernetes 控制平面暴露給不同租戶下的使用者，終端使用者可以使用 K8s 原生 API 或者服務提供商基於 CRDs/controllers 擴充套件出的介面。出於隔離的最基本需求，這裡不同租戶也需要透過名稱空間進行訪問上的邏輯隔離，同時保證不同租戶間網路和資源配額上的隔離。

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

![4.jpeg](https://ucc.alicdn.com/pic/developer-ecology/e210f6e7ab584d12b3bcaecf976f168f.jpeg)

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

雖然 Kubernetes 現有安全和排程能力還不足以完全安全地實施多租隔離，但是在如企業內部共享叢集這樣的應用場景下，透過名稱空間完成租戶間資源域的隔離，同時透過 RBAC、PodSecurityPolicy、NetworkPolicy 等策略模型控制租戶對資源訪問範圍和能力的限制，以及現有資源排程能力的結合，已經可以提供相當的安全隔離能力。而對於 SaaS、KaaS 這樣的服務平臺形態，我們可以透過阿里雲容器服務近期推出的[安全沙箱容器](https://help.aliyun.com/document_detail/142151.html?spm=a2c4g.11186623.6.628.5c5524765hhsVi)來實現容器核心級別的隔離，能夠最大程度的避免惡意租戶透過逃逸手段的跨租戶攻擊。

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

## 訪問控制

### AuthN & AuthZ & Admission
ACK 叢集的授權分為 RAM 授權和 RBAC 授權兩個步驟，其中 RAM 授權作用於叢集管理介面的訪問控制，包括對叢集的 CRUD 許可權（如叢集可見性、擴縮容、新增節點等操作），而 RBAC 授權用於叢集內部 Kubernetes 資源模型的訪問控制，可以做到指定資源在名稱空間粒度的細化授權。

ACK 授權管理為租戶內使用者提供了不同級別的預置角色模板，同時支援繫結多個使用者自定義的叢集角色，此外支援對批次使用者的授權。如需詳細瞭解 ACK 上叢集相關訪問控制授權，請參閱[相關幫助文件](https://help.aliyun.com/document_detail/119596.html?spm=a2c4g.11186623.6.585.385a2fc9sfG2vm)。

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

您可以在使用了 Terway 網路外掛的容器服務叢集上配置 NetworkPolicy，[這裡](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fgithub.com%2Fahmetb%2Fkubernetes-network-policy-recipes)可以獲得一些策略配置的示例。

### PodSecurityPolicy
PSP 是 K8s 原生的叢集維度的資源模型，它可以在apiserver中pod建立請求的 admission 階段校驗其執行時刻行為是否滿足對應 PSP 策略的約束，比如檢查 pod 是否使用了 host 的網路、檔案系統、指定埠、PID namespace 等，同時可以限制租戶內的使用者開啟特權（privileged）容器，限制掛盤型別，強制只讀掛載等能力；不僅如此，PSP 還可以基於繫結的策略給 pod 新增對應的 SecurityContext，包括容器執行時刻的 uid，gid 和新增或刪除的核心 capabilities 等多種設定。

關於如何開啟 PSP admission 和相關策略及許可權繫結的使用，可以參閱[這裡](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fzh%2Fdocs%2Fconcepts%2Fpolicy%2Fpod-security-policy%2F%23%25E4%25BB%2580%25E4%25B9%2588%25E6%2598%25AF-pod-%25E5%25AE%2589%25E5%2585%25A8%25E7%25AD%2596%25E7%2595%25A5)。

### OPA
OPA（Open Policy Agent）是一種功能強大的策略引擎，支援解耦式的 policy decisions 服務並且社群已經有了相對成熟的與 Kubernetes 的[整合方案](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fwww.openpolicyagent.org%2Fdocs%2Flatest%2Fkubernetes-admission-control)。當現有 RBAC 在名稱空間粒度的隔離不能夠滿足企業應用複雜的安全需求時，可以透過 OPA 提供 object 模型級別的細粒度訪問策略控制。

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

## 資源排程相關

### Resource Quotas & Limit Range
在多租戶場景下，不同團隊或部門共享叢集資源，難免會有資源競爭的情況發生，為此我們需要對每個租戶的資源使用配額做出限制。其中 ResourceQuota 用於限制租戶對應名稱空間下所有 pod 佔用的總資源 request 和 limit，LimitRange 用來設定租戶對應名稱空間中部署 pod 的預設資源 request 和 limit 值。另外我們還可以對租戶的儲存資源配額和物件數量配額進行限制。

關於資源配額的詳細指導可以參見[這裡](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fzh%2Fdocs%2Fconcepts%2Fpolicy%2Fresource-quotas%2F)。

### 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 新增同樣的容忍配置來訪問該節點，因此僅使用節點汙點和容忍機制還無法在非受信的多租叢集上保證目標節點的獨佔性。

關於如何使用節點汙點機制來控制排程，請參閱[這裡](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fdocs%2Fconcepts%2Fconfiguration%2Ftaint-and-toleration%2F)。

## 敏感資訊保護

### secrets encryption at REST
在多租戶叢集中不同租戶使用者共享同一套 etcd 儲存，在終端使用者可以訪問 Kubernetes 控制平面的場景下，我們需要保護 secrets 中的資料，避免在訪問控制策略配置不當情況下的敏感資訊洩露。為此可以參考 K8s 原生的 secret 加密能力，請參閱[這裡](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fkubernetes.io%2Fdocs%2Ftasks%2Fadminister-cluster%2Fencrypt-data%2F)。

ACK 也提供了基於阿里雲 KMS 服務的 secrets 加密開源解決方案，可以參閱[這裡](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fgithub.com%2FAliyunContainerService%2Fack-kms-plugin)。

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

- 開啟 Kubernetes 叢集的預設安全配置：開啟 RBAC 鑑權並實現基於namespace的軟隔離；開啟 secrets encryption 能力，增強敏感資訊保護；基於 CIS  Kubernetes  benchmarks 進行相應的安全配置；
- 開啟 NodeRestriction， AlwaysPullImages, PodSecurityPolicy 等相關 admission controllers；
- 透過 PSP 限制 pod 部署的特權模式，同時控制其執行時刻 SecurityContext；
- 配置 NetworkPolicy；
- 使用Resource Quota & Limit Range限制租戶的資源使用配額；
- 在應用執行時刻遵循許可權的最小化原則，儘可能縮小pod內容器的系統許可權；
- Log everything；
- 對接監控系統，實現容器應用維度的監控。

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

- 使用如 OPA 等動態策略引擎進行網路或 Object 級別的細粒度訪問控制；
- 使用安全容器實現容器執行時刻核心級別的安全隔離；
- 完備的監控、日誌、儲存等服務的多租隔離方案。

注意：[文中圖片來源](https://www.youtube.com/watch?v=RkY8u1_f5yY)。

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

K8s 實踐 | 如何解決多租戶叢集的安全隔離問題？

相關文章