Kubernetes多租戶集群的概念和常見的應(yīng)用模式

解決多租戶集群的安全隔離問題對于企業(yè)上云而言至關(guān)重要。本文討論了 Kubernetes 多租戶集群的概念和常見的應(yīng)用模式、企業(yè)內(nèi)共享集群的業(yè)務(wù)場景以及 Kubernetes 現(xiàn)有的安全管理功能！

什么是多租戶集群

首先，我們討論一下“租戶”是什么。租戶的概念不僅是集群用戶，還包括構(gòu)成計算、網(wǎng)絡(luò)、存儲和其他資源的工作負(fù)載集。在多租戶集群中，對單個集群中不同租戶進行隔離，這樣惡意租戶就無法攻擊其他租戶，共享集群資源也能合理地分配給租戶。根據(jù)隔離的安全級別，可以將集群分為軟隔離（Soft Multi-tenancy）和硬隔離（Hard Multi-tenancy）。軟隔離適用于企業(yè)內(nèi)的多租戶集群，因為默認(rèn)情況下不會有惡意租戶。在這種情況下，軟隔離主要是保護內(nèi)部團隊之間的業(yè)務(wù)并防護可能的安全攻擊。硬隔離適用于那些提供對外服務(wù)的服務(wù)提供商。由于業(yè)務(wù)模式，不能保證不同租戶中業(yè)務(wù)用戶的安全背景，所以集群中的租戶和 Kubernetes 系統(tǒng)可能會相互攻擊，這時需要嚴(yán)格的隔離以確保安全性。下面會對不同的多租戶方案進行更詳細(xì)的描述。

多租戶使用場景

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

企業(yè)內(nèi)共享集群的多租戶

這種場景下，所有集群用戶都來自企業(yè)，這也是許多 Kubernetes 集群客戶的使用場景。由于服務(wù)用戶的身份是可控的，因此這種業(yè)務(wù)模式的安全風(fēng)險也相對可控，畢竟老板可以直接開掉有問題的員工。根據(jù)企業(yè)內(nèi)部人員的結(jié)構(gòu)，企業(yè)可以通過命名空間，按照邏輯對不同部門或團隊的資源進行隔離。另外，定義具有以下角色的業(yè)務(wù)人員：

集群管理員

具有集群管理功能，例如伸縮容、添加節(jié)點等

為租戶管理員創(chuàng)建并分配命名空間

管理各種策略，例如 RAM、RBAC、NetworkPolicy 以及 quota

租戶管理員

至少擁有集群 RAM 只讀權(quán)限

管理租戶中相關(guān)人員的 RBAC 配置

租戶用戶

在租戶命名空間允許范圍內(nèi)使用 Kubernetes 資源

除了用戶角色的訪問控制之外，我們還要確保命名空間之間的網(wǎng)絡(luò)隔離，不同命名空間之間只允許白名單內(nèi)的跨租戶應(yīng)用程序請求。

SaaS 和 KaaS 服務(wù)模型中的多租戶

在 SaaS 多租戶場景中，Kubernetes 集群中的租戶是 SaaS 平臺和 SaaS 控制平面上的服務(wù)應(yīng)用程序?qū)嵗Ｔ谶@種場景下，平臺的服務(wù)應(yīng)用程序?qū)嵗譃椴煌拿臻g。服務(wù)的最終用戶無法與 Kubernetes 控制平面組件進行交互。這些最終用戶可以通過自定義的 SaaS 控制平面訪問和使用 SaaS 控制臺，使用服務(wù)或部署業(yè)務(wù)，如下左圖所示。例如，假設(shè)博客平臺已部署并在多租戶集群上運行。在這種情況下，租戶是每個客戶的博客實例和平臺的控制平面。平臺控制平面和每個托管博客都在不同的命名空間中運行。

KaaS 多租戶方案通常與云服務(wù)提供商有關(guān)。在這種場景下，業(yè)務(wù)平臺的服務(wù)通過 Kubernetes 控制平面直接暴露給不同租戶的用戶。最終用戶可以使用服務(wù)提供商提供的 Kubernetes API 或其他擴展 API。為了滿足隔離要求，不同的租戶同樣需要使用命名空間按照邏輯對訪問進行隔離，同時確保不同租戶的網(wǎng)絡(luò)和資源配額的隔離。

與企業(yè)內(nèi)的共享集群相反，這里的最終用戶都來自非受信區(qū)域，所以可能會有在服務(wù)平臺上運行惡意代碼的惡意租戶。對此，SaaS 和 KaaS 服務(wù)模型中的多租戶集群需要更強的安全隔離。在這種場景下，Kubernetes 現(xiàn)有的原生功能還無法滿足安全要求，因此需要在運行時進行內(nèi)核級別的隔離來增強此業(yè)務(wù)場景中的租戶安全性。

實施多租戶架構(gòu)

在規(guī)劃和實施多租戶集群時，我們首先要通過資源隔離模型來使用 Kubernetes 的資源隔離層，該模型會將集群本身、命名空間、節(jié)點、Pod 和容器分別分層。當(dāng)不同租戶的應(yīng)用程序負(fù)載共享相同的資源模型時，就可能會產(chǎn)生安全風(fēng)險，因此，在實施多租戶時，要控制每個租戶可訪問的資源域。在資源調(diào)度層面，還要確保處理敏感信息的容器只能運行在獨立的資源節(jié)點上。當(dāng)不同租戶的負(fù)載共享同一資源域時，我們可以使用運行時的資源調(diào)度控制策略來降低跨租戶攻擊的風(fēng)險。

盡管 Kubernetes 現(xiàn)有安全性和調(diào)度功能不足以實現(xiàn)租戶之間的完全安全隔離，但是可以通過命名空間隔離租戶使用的資源域，并使用 RBAC、PodSecurityPolicy、NetworkPolicy 等策略模型來控制租戶的資源訪問范圍以及資源調(diào)度功能。這種方法具有可靠的安全隔離能力。

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

訪問控制

NetworkPolicy

NetworkPolicy 控制不同租戶業(yè)務(wù) Pod 之間的網(wǎng)絡(luò)流量，并通過白名單進行跨租戶業(yè)務(wù)的訪問控制。

PodSecurityPolicy

PodSecurityPolicies（PSP）是 Kubernetes 中原生集群維度的資源模型，可以在創(chuàng)建 Pod 請求的準(zhǔn)入階段驗證該行為是否滿足相應(yīng) PSP 的要求，例如檢查 Pod 是否使用主機的網(wǎng)絡(luò)、文件系統(tǒng)、指定端口或 PID 命名空間。另外，它能限制租戶內(nèi)的用戶啟用特權(quán)容器，還會根據(jù)綁定的策略將相應(yīng)的 SecurityContext 添加到 Pod，包括容器運行時的 UID、GID 以及添加或刪除的內(nèi)核功能等設(shè)置。

OPA

Open Policy Agent（OPA）是一種功能強大的策略引擎，支持解耦的策略決策服務(wù)。目前，社區(qū)已經(jīng)有了成熟的 Kubernetes 集成解決方案。當(dāng)現(xiàn)有 RBAC 在命名空間級別上的隔離不能滿足企業(yè)應(yīng)用程序復(fù)雜的安全需求時，OPA 可以在對象模型級別提供細(xì)粒度的訪問策略控制。另外，OPA 還支持 7 層 NetworkPolicy 定義以及基于標(biāo)簽和注釋的跨命名空間訪問控制，可以有效增強 Kubernetes 原生的 NetworkPolicy。

資源調(diào)度

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

在多租戶場景中，不同的團隊或部門會共享集群資源，這可能導(dǎo)致資源競爭問題，需要通過限制每個租戶的資源使用配額來解決。ResourceQuota 用于限制總資源請求，以及租戶對應(yīng)命名空間下所有 Pod 的資源。LimitRange 用于設(shè)置租戶的命名空間中 Pod 的默認(rèn)資源請求和限制值。另外，我們還可以限制租戶的存儲資源配額和對象數(shù)量配額。

Pod 優(yōu)先級（Priority）和搶占（Preemption）

從 Kubernetes 1.14 版本開始，Pod 優(yōu)先級和搶占功能已成為重要組成部分。容器優(yōu)先級表示調(diào)度隊列中處于 pending 狀態(tài)容器的優(yōu)先級。由于節(jié)點資源不足或其他原因而無法調(diào)度高優(yōu)先級的 Pod 時，調(diào)度程序會嘗試驅(qū)逐低優(yōu)先級的 Pod，來保證可以先調(diào)度、部署高優(yōu)先級的 Pod。在多租戶方案中，優(yōu)先級和搶占的設(shè)置可以用來保護租戶中重要業(yè)務(wù)應(yīng)用程序的可用性。此外，Pod 優(yōu)先級與 ResourceQuota 搭配使用可將租戶配額限制設(shè)為指定的優(yōu)先級。

專用節(jié)點（Dedicated Nodes）

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

通過為集群中的某些節(jié)點添加 taint，可以將這些節(jié)點提供給指定租戶專用。在多租戶場景中，當(dāng)集群中包含 GPU 節(jié)點時，可以使用 taint 為需要 GPU 資源的業(yè)務(wù)應(yīng)用程序服務(wù)團隊保留這些節(jié)點。集群管理員可以使用諸如 effect：“NoSchedule” 之類的標(biāo)簽向節(jié)點添加污點，這樣就只能調(diào)度具有相應(yīng) tolerance 設(shè)置的 Pod 到該節(jié)點。但是，惡意租戶會將相同的 tolerance 設(shè)置添加到 Pod 上來訪問此節(jié)點，因此，僅使用節(jié)點 taint 和 tolerance 機制無法確保目標(biāo)節(jié)點在非信任多租戶集群中的安全性。

保護敏感信息—REST 的 secret 加密

在多租戶集群中，不同的租戶用戶共享一套相同的 etcd 存儲。當(dāng)最終用戶訪問 Kubernetes 控制平面時，要保護好 secret 數(shù)據(jù)，以避免訪問控制策略配置不正確時導(dǎo)致敏感信息泄漏。

總結(jié)

在部署多租戶體系架構(gòu)時，首先要確定相應(yīng)的應(yīng)用場景，包括租戶內(nèi)用戶和應(yīng)用程序的可信度和對應(yīng)的安全隔離程度。另外，為滿足基本的安全隔離要求，最好執(zhí)行以下幾點：

啟用 Kubernetes 集群默認(rèn)安全配置

啟用 RBAC，禁止匿名用戶訪問

啟用 secrets encryption，保護敏感信息

根據(jù) CIS Kubernetes 基準(zhǔn)執(zhí)行安全配置

啟用準(zhǔn)入控制器，例如 NodeRestriction、AlwaysPullImages 和 PodSecurityPolicy

使用 PSP 控制 Pod 部署的特權(quán)模式，并在 Pod 運行時控制 Pod 的安全上下文

配置 NetworkPolicy

Docker 運行時啟用 Seccomp、AppArmor 和 SELinux

對監(jiān)控、日志記錄等服務(wù)進行多租戶隔離

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

使用 OPA DENG 動態(tài)策略引擎在網(wǎng)絡(luò)或?qū)ο蠹墑e進行細(xì)粒度的訪問控制

部署安全容器，在容器運行時進行內(nèi)核級隔離

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

編輯：黃飛