云計算

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

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

什么是多租戶集群？

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

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

其中軟隔離更多的是面向企業(yè)內(nèi)部的多租需求，該形態(tài)下默認(rèn)不存在惡意租戶，隔離的目的是為了內(nèi)部團隊間的業(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 集群客戶的使用模式，因為服務(wù)使用者身份的可控性，相對來說這種業(yè)務(wù)形態(tài)的安全風(fēng)險是相對可控的，畢竟老板可以直接裁掉不懷好意的員工：）根據(jù)企業(yè)內(nèi)部人員結(jié)構(gòu)的復(fù)雜程度，我們可以通過命名空間對不同部門或團隊進(jìn)行資源的邏輯隔離，同時定義以下幾種角色的業(yè)務(wù)人員：

集群管理員：具有集群的管理能力（擴縮容、添加節(jié)點等操作）；負(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á)到限制容器運行時刻 capabilities 的目的。

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

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

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

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

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

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

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

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

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

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

訪問控制
AuthN & AuthZ & Admission

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

ACK 授權(quán)管理為租戶內(nèi)用戶提供了不同級別的預(yù)置角色模板，同時支持綁定多個用戶自定義的集群角色，此外支持對批量用戶的授權(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īng) PSP 策略的約束，比如檢查 pod 是否使用了 host 的網(wǎng)絡(luò)、文件系統(tǒng)、指定端口、PID namespace 等，同時可以限制租戶內(nèi)的用戶開啟特權(quán)（privileged）容器，限制掛盤類型，強制只讀掛載等能力；不僅如此，PSP 還可以基于綁定的策略給 pod 添加對應(yīng)的 SecurityContext，包括容器運行時刻的 uid，gid 和添加或刪除的內(nèi)核 capabilities 等多種設(shè)置。

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

OPA

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

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

資源調(diào)度相關(guān)
Resource Quotas & Limit Range

在多租戶場景下，不同團隊或部門共享集群資源，難免會有資源競爭的情況發(fā)生，為此我們需要對每個租戶的資源使用配額做出限制。其中 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)度隊列中等待的優(yōu)先級；而當(dāng)節(jié)點資源不足等原因造成高優(yōu)先的 pod 無法被調(diào)度時，scheduler 會嘗試驅(qū)逐低優(yōu)先級的 pod 來保證高優(yōu)先級 pod 可以被調(diào)度部署。

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

Dedicated Nodes

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

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

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

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

敏感信息保護(hù)
secrets encryption at REST

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

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

總結(jié)

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

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

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

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

注意：文中圖片來源。

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

總結(jié)

以上是生活随笔為你收集整理的K8s 实践 | 如何解决多租户集群的安全隔离问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。