解決多租戶集群的安全隔離問題對于企業上云而言至關重要。本文討論了 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 動態策略引擎在網絡或對象級別進行細粒度的訪問控制

部署安全容器，在容器運行時進行內核級隔離

對監視、日志記錄、存儲和其他服務實施全面的多租戶隔離解決方案

編輯：黃飛