K8s 實(shí)踐 | 如何解決多租戶集群的安全隔離問題？

作者 |?匡大虎? 阿里巴巴技術(shù)專家

導(dǎo)讀：如何解決多租戶集群的安全隔離問題是企業(yè)上云的一個(gè)關(guān)鍵問題，本文主要介紹 Kubernetes 多租戶集群的基本概念和常見應(yīng)用形態(tài)，以及在企業(yè)內(nèi)部共享集群的業(yè)務(wù)場景下，基于 Kubernetes 原生和 ACK 集群現(xiàn)有安全管理能力快速實(shí)現(xiàn)多租戶集群的相關(guān)方案。

什么是多租戶集群？

這里首先介紹一下"租戶"，租戶的概念不止局限于集群的用戶，它可以包含為一組計(jì)算，網(wǎng)絡(luò)，存儲等資源組成的工作負(fù)載集合。而在多租戶集群中，需要在一個(gè)集群范圍內(nèi)（未來可能會是多集群）對不同的租戶提供盡可能的安全隔離，以最大程度的避免惡意租戶對其他租戶的***，同時(shí)需要保證租戶之間公平地分配共享集群資源。

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

• 其中軟隔離更多的是面向企業(yè)內(nèi)部的多租需求，該形態(tài)下默認(rèn)不存在惡意租戶，隔離的目的是為了內(nèi)部團(tuán)隊(duì)間的業(yè)務(wù)保護(hù)和對可能的安全***進(jìn)行防護(hù)；
• 而硬隔離面向的更多是對外提供服務(wù)的服務(wù)供應(yīng)商，由于該業(yè)務(wù)形態(tài)下無法保證不同租戶中業(yè)務(wù)使用者的安全背景，我們默認(rèn)認(rèn)為租戶之間以及租戶與 K8s 系統(tǒng)之間是存在互相***的可能，因此這里也需要更嚴(yán)格的隔離作為安全保障。

關(guān)于多租戶的不同應(yīng)用場景，在下節(jié)會有更細(xì)致的介紹。

多租戶應(yīng)用場景

下面介紹一下典型的兩種企業(yè)多租戶應(yīng)用場景和不同的隔離需求：

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

該場景下集群的所有用戶均來自企業(yè)內(nèi)部，這也是當(dāng)前很多 K8s 集群客戶的使用模式，因?yàn)榉?wù)使用者身份的可控性，相對來說這種業(yè)務(wù)形態(tài)的安全風(fēng)險(xiǎn)是相對可控的，畢竟老板可以直接裁掉不懷好意的員工：）根據(jù)企業(yè)內(nèi)部人員結(jié)構(gòu)的復(fù)雜程度，我們可以通過命名空間對不同部門或團(tuán)隊(duì)進(jìn)行資源的邏輯隔離，同時(shí)定義以下幾種角色的業(yè)務(wù)人員：

• 集群管理員：具有集群的管理能力（擴(kuò)縮容、添加節(jié)點(diǎn)等操作）；負(fù)責(zé)為租戶管理員創(chuàng)建和分配命名空間；負(fù)責(zé)各類策略（RAM/RBAC/networkpolicy/quota...）的 CRUD；
• 租戶管理員：至少具有集群的 RAM 只讀權(quán)限；管理租戶內(nèi)相關(guān)人員的 RBAC 配置；
• 租戶內(nèi)用戶：在租戶對應(yīng)命名空間內(nèi)使用權(quán)限范圍內(nèi)的 K8s 資源。

在建立了基于用戶角色的訪問控制基礎(chǔ)上，我們還需要保證命名空間之間的網(wǎng)絡(luò)隔離，在不同的命名空間之間只能夠允許白名單范圍內(nèi)的跨租戶應(yīng)用請求。

另外，對于業(yè)務(wù)安全等級要求較高的應(yīng)用場景，我們需要限制應(yīng)用容器的內(nèi)核能力，可以配合 seccomp / AppArmor / SELinux 等策略工具達(dá)到限制容器運(yùn)行時(shí)刻 capabilities 的目的。

當(dāng)然 Kubernetes 現(xiàn)有的命名空間單層邏輯隔離還不足以滿足一部分大型企業(yè)應(yīng)用復(fù)雜業(yè)務(wù)模型對隔離需求，我們可以關(guān)注?Virtual Cluster，它通過抽象出更高級別的租戶資源模型來實(shí)現(xiàn)更精細(xì)化的多租管理，以此彌補(bǔ)原生命名空間能力上的不足。

SaaS & KaaS 服務(wù)模型下的多租戶

在 SaaS 多租場景下， Kubernetes 集群中的租戶對應(yīng)為 SaaS 平臺中各服務(wù)應(yīng)用實(shí)例和 SaaS 自身控制平面，該場景下可以將平臺各服務(wù)應(yīng)用實(shí)例劃分到彼此不同的命名空間中。而服務(wù)的最終用戶是無法與 Kubernetes 的控制平面組件進(jìn)行交互，這些最終用戶能夠看到和使用的是 SaaS 自身控制臺，他們通過上層定制化的 SaaS 控制平面使用服務(wù)或部署業(yè)務(wù)（如下左圖所示）。

例如，某博客平臺部署在多租戶集群上運(yùn)行。在該場景下，租戶是每個(gè)客戶的博客實(shí)例和平臺自己的控制平面。平臺的控制平面和每個(gè)托管博客都將在不同的命名空間中運(yùn)行?？蛻魧⑼ㄟ^平臺的界面來創(chuàng)建和刪除博客、更新博客軟件版本，但無法了解集群的運(yùn)作方式。

KaaS 多租場景常見于云服務(wù)提供商，該場景下業(yè)務(wù)平臺的服務(wù)直接通過 Kubernetes 控制平面暴露給不同租戶下的用戶，最終用戶可以使用 K8s 原生 API 或者服務(wù)提供商基于 CRDs/controllers 擴(kuò)展出的接口。出于隔離的最基本需求，這里不同租戶也需要通過命名空間進(jìn)行訪問上的邏輯隔離，同時(shí)保證不同租戶間網(wǎng)絡(luò)和資源配額上的隔離。

與企業(yè)內(nèi)部共享集群不同，這里的最終用戶均來自非受信域，他們當(dāng)中不可避免的存在惡意租戶在服務(wù)平臺上執(zhí)行惡意代碼，因此對于 SaaS/KaaS 服務(wù)模型下的多租戶集群，我們需要更高標(biāo)準(zhǔn)的安全隔離，而 Kubernetes 現(xiàn)有原生能力還不足以滿足安全上的需求，為此我們需要如安全容器這樣在容器運(yùn)行時(shí)刻內(nèi)核級別的隔離來強(qiáng)化該業(yè)務(wù)形態(tài)下的租戶安全。

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

在規(guī)劃和實(shí)施多租戶集群時(shí)，我們首先可以利用的是 Kubernetes 自身的資源隔離層，包括集群本身、命名空間、節(jié)點(diǎn)、pod 和容器均是不同層次的資源隔離模型。當(dāng)不同租戶的應(yīng)用負(fù)載能夠共享相同的資源模型時(shí)，就會存在彼此之間的安全隱患。為此，我們需要在實(shí)施多租時(shí)控制每個(gè)租戶能夠訪問到的資源域，同時(shí)在資源調(diào)度層面盡可能的保證處理敏感信息的容器運(yùn)行在相對獨(dú)立的資源節(jié)點(diǎn)內(nèi)；如果出于資源開銷的角度，當(dāng)有來自不同租戶的負(fù)載共享同一個(gè)資源域時(shí)，可以通過運(yùn)行時(shí)刻的安全和資源調(diào)度控制策略減少跨租戶***的風(fēng)險(xiǎn)。

雖然 Kubernetes 現(xiàn)有安全和調(diào)度能力還不足以完全安全地實(shí)施多租隔離，但是在如企業(yè)內(nèi)部共享集群這樣的應(yīng)用場景下，通過命名空間完成租戶間資源域的隔離，同時(shí)通過 RBAC、PodSecurityPolicy、NetworkPolicy 等策略模型控制租戶對資源訪問范圍和能力的限制，以及現(xiàn)有資源調(diào)度能力的結(jié)合，已經(jīng)可以提供相當(dāng)?shù)陌踩綦x能力。而對于 SaaS、KaaS 這樣的服務(wù)平臺形態(tài)，我們可以通過阿里云容器服務(wù)近期推出的安全沙箱容器來實(shí)現(xiàn)容器內(nèi)核級別的隔離，能夠最大程度的避免惡意租戶通過逃逸手段的跨租戶***。

本節(jié)重點(diǎn)關(guān)注基于 Kubernetes 原生安全能力的多租戶實(shí)踐。

訪問控制

AuthN & AuthZ & Admission

ACK 集群的授權(quán)分為 RAM 授權(quán)和 RBAC 授權(quán)兩個(gè)步驟，其中 RAM 授權(quán)作用于集群管理接口的訪問控制，包括對集群的 CRUD 權(quán)限（如集群可見性、擴(kuò)縮容、添加節(jié)點(diǎn)等操作），而 RBAC 授權(quán)用于集群內(nèi)部 Kubernetes 資源模型的訪問控制，可以做到指定資源在命名空間粒度的細(xì)化授權(quán)。

ACK 授權(quán)管理為租戶內(nèi)用戶提供了不同級別的預(yù)置角色模板，同時(shí)支持綁定多個(gè)用戶自定義的集群角色，此外支持對批量用戶的授權(quán)。如需詳細(xì)了解 ACK 上集群相關(guān)訪問控制授權(quán)，請參閱相關(guān)幫助文檔。

NetworkPolicy

NetworkPolicy 可以控制不同租戶業(yè)務(wù) pod 之間的網(wǎng)絡(luò)流量，另外可以通過白名單的方式打開跨租戶之間的業(yè)務(wù)訪問限制。

您可以在使用了 Terway 網(wǎng)絡(luò)插件的容器服務(wù)集群上配置 NetworkPolicy，這里可以獲得一些策略配置的示例。

PodSecurityPolicy

PSP 是 K8s 原生的集群維度的資源模型，它可以在apiserver中pod創(chuàng)建請求的 admission 階段校驗(yàn)其運(yùn)行時(shí)刻行為是否滿足對應(yīng) PSP 策略的約束，比如檢查 pod 是否使用了 host 的網(wǎng)絡(luò)、文件系統(tǒng)、指定端口、PID namespace 等，同時(shí)可以限制租戶內(nèi)的用戶開啟特權(quán)（privileged）容器，限制掛盤類型，強(qiáng)制只讀掛載等能力；不僅如此，PSP 還可以基于綁定的策略給 pod 添加對應(yīng)的 SecurityContext，包括容器運(yùn)行時(shí)刻的 uid，gid 和添加或刪除的內(nèi)核 capabilities 等多種設(shè)置。

關(guān)于如何開啟 PSP admission 和相關(guān)策略及權(quán)限綁定的使用，可以參閱這里。

OPA

OPA（Open Policy Agent）是一種功能強(qiáng)大的策略引擎，支持解耦式的 policy decisions 服務(wù)并且社區(qū)已經(jīng)有了相對成熟的與 Kubernetes 的集成方案。當(dāng)現(xiàn)有 RBAC 在命名空間粒度的隔離不能夠滿足企業(yè)應(yīng)用復(fù)雜的安全需求時(shí)，可以通過 OPA 提供 object 模型級別的細(xì)粒度訪問策略控制。

同時(shí) OPA 支持七層的 NetworkPolicy 策略定義及基于 labels/annotation 的跨命名空間訪問控制，可以作為 K8s 原生 NetworkPolicy 的有效增強(qiáng)。

資源調(diào)度相關(guān)

Resource Quotas & Limit Range

在多租戶場景下，不同團(tuán)隊(duì)或部門共享集群資源，難免會有資源競爭的情況發(fā)生，為此我們需要對每個(gè)租戶的資源使用配額做出限制。其中 ResourceQuota 用于限制租戶對應(yīng)命名空間下所有 pod 占用的總資源 request 和 limit，LimitRange 用來設(shè)置租戶對應(yīng)命名空間中部署 pod 的默認(rèn)資源 request 和 limit 值。另外我們還可以對租戶的存儲資源配額和對象數(shù)量配額進(jìn)行限制。

關(guān)于資源配額的詳細(xì)指導(dǎo)可以參見這里。

Pod Priority/Preemption

從 1.14 版本開始 pod 的優(yōu)先級和搶占已經(jīng)從 beta 成為穩(wěn)定特性，其中 pod priority 標(biāo)識了 pod 在 pending 狀態(tài)的調(diào)度隊(duì)列中等待的優(yōu)先級；而當(dāng)節(jié)點(diǎn)資源不足等原因造成高優(yōu)先的 pod 無法被調(diào)度時(shí)，scheduler 會嘗試驅(qū)逐低優(yōu)先級的 pod 來保證高優(yōu)先級 pod 可以被調(diào)度部署。

在多租戶場景下，可以通過優(yōu)先級和搶占設(shè)置確保租戶內(nèi)重要業(yè)務(wù)應(yīng)用的可用性；同時(shí) pod priority 可以和 ResouceQuota 配合使用，完成租戶在指定優(yōu)先級下有多少配額的限制。

Dedicated Nodes

注意：惡意租戶可以規(guī)避由節(jié)點(diǎn)污點(diǎn)和容忍機(jī)制強(qiáng)制執(zhí)行的策略。以下說明僅用于企業(yè)內(nèi)部受信任租戶集群，或租戶無法直接訪問 Kubernetes 控制平面的集群。

通過對集群中的某些節(jié)點(diǎn)添加污點(diǎn)，可以將這些節(jié)點(diǎn)用于指定幾個(gè)租戶專門使用。在多租戶場景下，例如集群中的 GPU 節(jié)點(diǎn)可以通過污點(diǎn)的方式保留給業(yè)務(wù)應(yīng)用中需要使用到 GPU 的服務(wù)團(tuán)隊(duì)使用。集群管理員可以通過如 effect: "NoSchedule" 這樣的標(biāo)簽給節(jié)點(diǎn)添加污點(diǎn)，同時(shí)只有配置了相應(yīng)容忍設(shè)置的 pod 可以被調(diào)度到該節(jié)點(diǎn)上。

當(dāng)然惡意租戶可以同樣通過給自身 pod 添加同樣的容忍配置來訪問該節(jié)點(diǎn)，因此僅使用節(jié)點(diǎn)污點(diǎn)和容忍機(jī)制還無法在非受信的多租集群上保證目標(biāo)節(jié)點(diǎn)的獨(dú)占性。

關(guān)于如何使用節(jié)點(diǎn)污點(diǎn)機(jī)制來控制調(diào)度，請參閱這里。

敏感信息保護(hù)

secrets encryption at REST

在多租戶集群中不同租戶用戶共享同一套 etcd 存儲，在最終用戶可以訪問 Kubernetes 控制平面的場景下，我們需要保護(hù) secrets 中的數(shù)據(jù)，避免在訪問控制策略配置不當(dāng)情況下的敏感信息泄露。為此可以參考 K8s 原生的 secret 加密能力，請參閱這里。

ACK 也提供了基于阿里云 KMS 服務(wù)的 secrets 加密開源解決方案，可以參閱這里。

總結(jié)

在實(shí)施多租戶架構(gòu)時(shí)首先需要確定對應(yīng)的應(yīng)用場景，包括判斷租戶內(nèi)用戶和應(yīng)用負(fù)載的可信程度以及對應(yīng)的安全隔離程度。在此基礎(chǔ)上以下幾點(diǎn)是安全隔離的基本需求：

• 開啟 Kubernetes 集群的默認(rèn)安全配置：開啟 RBAC 鑒權(quán)并實(shí)現(xiàn)基于namespace的軟隔離；開啟 secrets encryption 能力，增強(qiáng)敏感信息保護(hù)；基于 CIS Kubernetes benchmarks 進(jìn)行相應(yīng)的安全配置；
• 開啟 NodeRestriction， AlwaysPullImages, PodSecurityPolicy 等相關(guān) admission controllers；
• 通過 PSP 限制 pod 部署的特權(quán)模式，同時(shí)控制其運(yùn)行時(shí)刻 SecurityContext；
• 配置 NetworkPolicy；
• 使用Resource Quota & Limit Range限制租戶的資源使用配額；
• 在應(yīng)用運(yùn)行時(shí)刻遵循權(quán)限的最小化原則，盡可能縮小pod內(nèi)容器的系統(tǒng)權(quán)限；
• Log everything；
• 對接監(jiān)控系統(tǒng)，實(shí)現(xiàn)容器應(yīng)用維度的監(jiān)控。

而對于如 SaaS、KaaS 等服務(wù)模型下，或者我們無法保證租戶內(nèi)用戶的可信程度時(shí)，我們需要采取一些更強(qiáng)有力的隔離手段，比如：

• 使用如 OPA 等動(dòng)態(tài)策略引擎進(jìn)行網(wǎng)絡(luò)或 Object 級別的細(xì)粒度訪問控制；
• 使用安全容器實(shí)現(xiàn)容器運(yùn)行時(shí)刻內(nèi)核級別的安全隔離；
• 完備的監(jiān)控、日志、存儲等服務(wù)的多租隔離方案。

注意：文中圖片來源。

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)圈。”