解決多租戶叢集的安全隔離問題對於企業上雲而言至關重要。本文討論了 Kubernetes 多租戶叢集的概念和常見的應用模式、企業內共享叢集的業務場景以及 Kubernetes 現有的安全管理功能。

什麼是多租戶叢集

首先，我們討論一下“租戶”是什麼。租戶的概念不僅是叢集使用者，還包括構成計算、網路、儲存和其他資源的工作負載集。在多租戶叢集中，對單個叢集中不同租戶進行隔離，這樣惡意租戶就無法攻擊其他租戶，共享叢集資源也能合理地分配給租戶。根據隔離的安全級別，可以將叢集分為軟隔離（Soft Multi-tenancy）和硬隔離（Hard Multi-tenancy）。軟隔離適用於企業內的多租戶叢集，因為預設情況下不會有惡意租戶。在這種情況下，軟隔離主要是保護內部團隊之間的業務並防護可能的安全攻擊。硬隔離適用於那些提供對外服務的服務提供商。由於業務模式，不能保證不同租戶中業務使用者的安全背景，所以叢集中的租戶和 Kubernetes 系統可能會相互攻擊，這時需要嚴格的隔離以確保安全性。下面會對不同的多租戶方案進行更詳細的描述。

多租戶使用場景

下面介紹兩種不同隔離要求的企業多租戶方案：

企業內共享叢集的多租戶

這種場景下，所有叢集使用者都來自企業，這也是許多 Kubernetes 叢集客戶的使用場景。由於服務使用者的身份是可控的，因此這種業務模式的安全風險也相對可控，畢竟老闆可以直接開掉有問題的員工。根據企業內部人員的結構，企業可以透過名稱空間，按照邏輯對不同部門或團隊的資源進行隔離。另外，定義具有以下角色的業務人員：

叢集管理員

具有叢集管理功能，例如伸縮容、新增節點等
為租戶管理員建立並分配名稱空間
管理各種策略，例如 RAM、RBAC、NetworkPolicy 以及 quota

租戶管理員

至少擁有叢集 RAM 只讀許可權
管理租戶中相關人員的 RBAC 配置

租戶使用者

在租戶名稱空間允許範圍內使用 Kubernetes 資源

除了使用者角色的訪問控制之外，我們還要確保名稱空間之間的網路隔離，不同名稱空間之間只允許白名單內的跨租戶應用程式請求。

SaaS 和 KaaS 服務模型中的多租戶

在 SaaS 多租戶場景中，Kubernetes 叢集中的租戶是 SaaS 平臺和 SaaS 控制平面上的服務應用程式例項。在這種場景下，平臺的服務應用程式例項分為不同的名稱空間。服務的終端使用者無法與 Kubernetes 控制平面元件進行互動。這些終端使用者可以透過自定義的 SaaS 控制平面訪問和使用 SaaS 控制檯，使用服務或部署業務，如下左圖所示。例如，假設部落格平臺已部署並在多租戶叢集上執行。在這種情況下，租戶是每個客戶的部落格例項和平臺的控制平面。平臺控制平面和每個託管部落格都在不同的名稱空間中執行。

KaaS 多租戶方案通常與雲服務提供商有關。在這種場景下，業務平臺的服務透過 Kubernetes 控制平面直接暴露給不同租戶的使用者。終端使用者可以使用服務提供商提供的 Kubernetes API 或其他擴充套件 API。為了滿足隔離要求，不同的租戶同樣需要使用名稱空間按照邏輯對訪問進行隔離，同時確保不同租戶的網路和資源配額的隔離。

與企業內的共享叢集相反，這裡的終端使用者都來自非受信區域，所以可能會有在服務平臺上執行惡意程式碼的惡意租戶。對此，SaaS 和 KaaS 服務模型中的多租戶叢集需要更強的安全隔離。在這種場景下，Kubernetes 現有的原生功能還無法滿足安全要求，因此需要在執行時進行核心級別的隔離來增強此業務場景中的租戶安全性。

實施多租戶架構

在規劃和實施多租戶叢集時，我們首先要透過資源隔離模型來使用 Kubernetes 的資源隔離層，該模型會將叢集本身、名稱空間、節點、Pod 和容器分別分層。當不同租戶的應用程式負載共享相同的資源模型時，就可能會產生安全風險，因此，在實施多租戶時，要控制每個租戶可訪問的資源域。在資源排程層面，還要確保處理敏感資訊的容器只能執行在獨立的資源節點上。當不同租戶的負載共享同一資源域時，我們可以使用執行時的資源排程控制策略來降低跨租戶攻擊的風險。

儘管 Kubernetes 現有安全性和排程功能不足以實現租戶之間的完全安全隔離，但是可以透過名稱空間隔離租戶使用的資源域，並使用 RBAC、PodSecurityPolicy、NetworkPolicy 等策略模型來控制租戶的資源訪問範圍以及資源排程功能。這種方法具有可靠的安全隔離能力。

以下部分重點介紹基於 Kubernetes 原生安全功能的多租戶實踐。

訪問控制

NetworkPolicy

NetworkPolicy 控制不同租戶業務 Pod 之間的網路流量，並透過白名單進行跨租戶業務的訪問控制。

PodSecurityPolicy

PodSecurityPolicies（PSP）是 Kubernetes 中原生叢集維度的資源模型，可以在建立 Pod 請求的准入階段驗證該行為是否滿足相應 PSP 的要求，例如檢查 Pod 是否使用主機的網路、檔案系統、指定埠或 PID 名稱空間。另外，它能限制租戶內的使用者啟用特權容器，還會根據繫結的策略將相應的 SecurityContext 新增到 Pod，包括容器執行時的 UID、GID 以及新增或刪除的核心功能等設定。

OPA

Open Policy Agent（OPA）是一種功能強大的策略引擎，支援解耦的策略決策服務。目前，社群已經有了成熟的 Kubernetes 整合解決方案。當現有 RBAC 在名稱空間級別上的隔離不能滿足企業應用程式複雜的安全需求時，OPA 可以在物件模型級別提供細粒度的訪問策略控制。另外，OPA 還支援 7 層 NetworkPolicy 定義以及基於標籤和註釋的跨名稱空間訪問控制，可以有效增強 Kubernetes 原生的 NetworkPolicy。

資源排程

資源配額（ResourceQuota）和限制範圍（LimitRange）

在多租戶場景中，不同的團隊或部門會共享叢集資源，這可能導致資源競爭問題，需要透過限制每個租戶的資源使用配額來解決。ResourceQuota 用於限制總資源請求，以及租戶對應名稱空間下所有 Pod 的資源。LimitRange 用於設定租戶的名稱空間中 Pod 的預設資源請求和限制值。另外，我們還可以限制租戶的儲存資源配額和物件數量配額。

Pod 優先順序（Priority）和搶佔（Preemption）

從 Kubernetes 1.14 版本開始，Pod 優先順序和搶佔功能已成為重要組成部分。容器優先順序表示排程佇列中處於 pending 狀態容器的優先順序。由於節點資源不足或其他原因而無法排程高優先順序的 Pod 時，排程程式會嘗試驅逐低優先順序的 Pod，來保證可以先排程、部署高優先順序的 Pod。在多租戶方案中，優先順序和搶佔的設定可以用來保護租戶中重要業務應用程式的可用性。此外，Pod 優先順序與 ResourceQuota 搭配使用可將租戶配額限制設為指定的優先順序。

專用節點（Dedicated Nodes）

注意：惡意租戶可能繞過節點 taint 和 tolerance 機制強制實施策略。以下內容僅適用於企業內受信任租戶的叢集，或租戶無法直接訪問 Kubernetes 控制平面的叢集。

透過為叢集中的某些節點新增 taint，可以將這些節點提供給指定租戶專用。在多租戶場景中，當叢集中包含 GPU 節點時，可以使用 taint 為需要 GPU 資源的業務應用程式服務團隊保留這些節點。叢集管理員可以使用諸如 effect：“NoSchedule” 之類的標籤向節點新增汙點，這樣就只能排程具有相應 tolerance 設定的 Pod 到該節點。但是，惡意租戶會將相同的 tolerance 設定新增到 Pod 上來訪問此節點，因此，僅使用節點 taint 和 tolerance 機制無法確保目標節點在非信任多租戶叢集中的安全性。

保護敏感資訊—REST 的 secret 加密

在多租戶叢集中，不同的租戶使用者共享一套相同的 etcd 儲存。當終端使用者訪問 Kubernetes 控制平面時，要保護好 secret 資料，以避免訪問控制策略配置不正確時導致敏感資訊洩漏。

總結

在部署多租戶體系架構時，首先要確定相應的應用場景，包括租戶內使用者和應用程式的可信度和對應的安全隔離程度。另外，為滿足基本的安全隔離要求，最好執行以下幾點：

啟用 Kubernetes 叢集預設安全配置
啟用 RBAC，禁止匿名使用者訪問
啟用 secrets encryption，保護敏感資訊
根據 CIS Kubernetes 基準執行安全配置
啟用准入控制器，例如 NodeRestriction、AlwaysPullImages 和 PodSecurityPolicy
使用 PSP 控制 Pod 部署的特權模式，並在 Pod 執行時控制 Pod 的安全上下文
配置 NetworkPolicy
Docker 執行時啟用 Seccomp、AppArmor 和 SELinux
對監控、日誌記錄等服務進行多租戶隔離

當使用諸如 SaaS 和 KaaS 之類的服務模型時，或者無法保證租戶下使用者的可信度時，可以使用以下更強力的隔離措施：

使用 OPA DENG 動態策略引擎在網路或物件級別進行細粒度的訪問控制
部署安全容器，在容器執行時進行核心級隔離
對監視、日誌記錄、儲存和其他服務實施全面的多租戶隔離解決方案

連結：https://www.sohu.com/a/662616835_121124376

如何解決 K8s 多租戶叢集的安全隔離難題？