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

什么是多租戶集群

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

多租戶使用場(chǎng)景

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

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

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

集群管理員

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

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

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

租戶管理員

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

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

租戶用戶

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

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

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

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

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

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

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

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

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

以下部分重點(diǎn)介紹基于 Kubernetes 原生安全功能的多租戶實(shí)踐。

訪問控制

NetworkPolicy

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

PodSecurityPolicy

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

OPA

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

資源調(diào)度

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

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

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

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

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

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

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

保護(hù)敏感信息—REST 的 secret 加密

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

總結(jié)

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

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

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

啟用 secrets encryption，保護(hù)敏感信息

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

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

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

配置 NetworkPolicy

Docker 運(yùn)行時(shí)啟用 Seccomp、AppArmor 和 SELinux

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

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

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

部署安全容器，在容器運(yùn)行時(shí)進(jìn)行內(nèi)核級(jí)隔離

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

編輯：黃飛