K8s 實踐 | 如何解決多租戶集羣的安全隔離問題？

做者 | 匡大虎  阿里巴巴技術專家

導讀：如何解決多租戶集羣的安全隔離問題是企業上雲的一個關鍵問題，本文主要介紹 Kubernetes 多租戶集羣的基本概念和常見應用形態，以及在企業內部共享集羣的業務場景下，基於 Kubernetes 原生和 ACK 集羣現有安全管理能力快速實現多租戶集羣的相關方案。

什麼是多租戶集羣？

這裏首先介紹一下"租戶"，租戶的概念不止侷限於集羣的用戶，它能夠包含爲一組計算，網絡，存儲等資源組成的工做負載集合。而在多租戶集羣中，須要在一個集羣範圍內（將來可能會是多集羣）對不一樣的租戶提供儘量的安全隔離，以最大程度的避免惡意租戶對其餘租戶的***，同時須要保證租戶之間公平地分配共享集羣資源。

在隔離的安全程度上，咱們能夠將其分爲軟隔離 (Soft Multi-tenancy) 和硬隔離 (Hard Multi-tenancy) 兩種。

• 其中軟隔離更多的是面向企業內部的多租需求，該形態下默認不存在惡意租戶，隔離的目的是爲了內部團隊間的業務保護和對可能的安全***進行防禦；
• 而硬隔離面向的更可能是對外提供服務的服務供應商，因爲該業務形態下沒法保證不一樣租戶中業務使用者的安全背景，咱們默認認爲租戶之間以及租戶與 K8s 系統之間是存在互相***的可能，所以這裏也須要更嚴格的隔離做爲安全保障。

關於多租戶的不一樣應用場景，在下節會有更細緻的介紹。

多租戶應用場景

下面介紹一下典型的兩種企業多租戶應用場景和不一樣的隔離需求：

企業內部共享集羣的多租戶

該場景下集羣的全部用戶均來自企業內部，這也是當前不少 K8s 集羣客戶的使用模式，由於服務使用者身份的可控性，相對來講這種業務形態的安全風險是相對可控的，畢竟老闆能夠直接裁掉不懷好意的員工：）根據企業內部人員結構的複雜程度，咱們能夠經過命名空間對不一樣部門或團隊進行資源的邏輯隔離，同時定義如下幾種角色的業務人員：

• 集羣管理員：具備集羣的管理能力（擴縮容、添加節點等操做）；負責爲租戶管理員建立和分配命名空間；負責各種策略（RAM/RBAC/networkpolicy/quota...）的 CRUD；
• 租戶管理員：至少具備集羣的 RAM 只讀權限；管理租戶內相關人員的 RBAC 配置；
• 租戶內用戶：在租戶對應命名空間內使用權限範圍內的 K8s 資源。

在創建了基於用戶角色的訪問控制基礎上，咱們還須要保證命名空間之間的網絡隔離，在不一樣的命名空間之間只可以容許白名單範圍內的跨租戶應用請求。

另外，對於業務安全等級要求較高的應用場景，咱們須要限制應用容器的內核能力，能夠配合 seccomp / AppArmor / SELinux 等策略工具達到限制容器運行時刻 capabilities 的目的。

固然 Kubernetes 現有的命名空間單層邏輯隔離還不足以知足一部分大型企業應用複雜業務模型對隔離需求，咱們能夠關注 Virtual Cluster，它經過抽象出更高級別的租戶資源模型來實現更精細化的多租管理，以此彌補原生命名空間能力上的不足。

SaaS & KaaS 服務模型下的多租戶

在 SaaS 多租場景下， Kubernetes 集羣中的租戶對應爲 SaaS 平臺中各服務應用實例和 SaaS 自身控制平面，該場景下能夠將平臺各服務應用實例劃分到彼此不一樣的命名空間中。而服務的最終用戶是沒法與 Kubernetes 的控制平面組件進行交互，這些最終用戶可以看到和使用的是 SaaS 自身控制檯，他們經過上層定製化的 SaaS 控制平面使用服務或部署業務（以下左圖所示）。

例如，某博客平臺部署在多租戶集羣上運行。在該場景下，租戶是每一個客戶的博客實例和平臺本身的控制平面。平臺的控制平面和每一個託管博客都將在不一樣的命名空間中運行。客戶將經過平臺的界面來建立和刪除博客、更新博客軟件版本，但沒法瞭解集羣的運做方式。

KaaS 多租場景常見於雲服務提供商，該場景下業務平臺的服務直接經過 Kubernetes 控制平面暴露給不一樣租戶下的用戶，最終用戶可使用 K8s 原生 API 或者服務提供商基於 CRDs/controllers 擴展出的接口。出於隔離的最基本需求，這裏不一樣租戶也須要經過命名空間進行訪問上的邏輯隔離，同時保證不一樣租戶間網絡和資源配額上的隔離。

與企業內部共享集羣不一樣，這裏的最終用戶均來自非受信域，他們當中不可避免的存在惡意租戶在服務平臺上執行惡意代碼，所以對於 SaaS/KaaS 服務模型下的多租戶集羣，咱們須要更高標準的安全隔離，而 Kubernetes 現有原生能力還不足以知足安全上的需求，爲此咱們須要如安全容器這樣在容器運行時刻內核級別的隔離來強化該業務形態下的租戶安全。

實施多租戶架構

在規劃和實施多租戶集羣時，咱們首先能夠利用的是 Kubernetes 自身的資源隔離層，包括集羣自己、命名空間、節點、pod 和容器均是不一樣層次的資源隔離模型。當不一樣租戶的應用負載可以共享相同的資源模型時，就會存在彼此之間的安全隱患。爲此，咱們須要在實施多租時控制每一個租戶可以訪問到的資源域，同時在資源調度層面儘量的保證處理敏感信息的容器運行在相對獨立的資源節點內；若是出於資源開銷的角度，當有來自不一樣租戶的負載共享同一個資源域時，能夠經過運行時刻的安全和資源調度控制策略減小跨租戶***的風險。

雖然 Kubernetes 現有安全和調度能力還不足以徹底安全地實施多租隔離，可是在如企業內部共享集羣這樣的應用場景下，經過命名空間完成租戶間資源域的隔離，同時經過 RBAC、PodSecurityPolicy、NetworkPolicy 等策略模型控制租戶對資源訪問範圍和能力的限制，以及現有資源調度能力的結合，已經能夠提供至關的安全隔離能力。而對於 SaaS、KaaS 這樣的服務平臺形態，咱們能夠經過阿里雲容器服務近期推出的安全沙箱容器來實現容器內核級別的隔離，可以最大程度的避免惡意租戶經過逃逸手段的跨租戶***。

本節重點關注基於 Kubernetes 原生安全能力的多租戶實踐。

訪問控制

AuthN & AuthZ & Admission

ACK 集羣的受權分爲 RAM 受權和 RBAC 受權兩個步驟，其中 RAM 受權做用於集羣管理接口的訪問控制，包括對集羣的 CRUD 權限（如集羣可見性、擴縮容、添加節點等操做），而 RBAC 受權用於集羣內部 Kubernetes 資源模型的訪問控制，能夠作到指定資源在命名空間粒度的細化受權。

ACK 受權管理爲租戶內用戶提供了不一樣級別的預置角色模板，同時支持綁定多個用戶自定義的集羣角色，此外支持對批量用戶的受權。如需詳細瞭解 ACK 上集羣相關訪問控制受權，請參閱相關幫助文檔。

NetworkPolicy

NetworkPolicy 能夠控制不一樣租戶業務 pod 之間的網絡流量，另外能夠經過白名單的方式打開跨租戶之間的業務訪問限制。

您能夠在使用了 Terway 網絡插件的容器服務集羣上配置 NetworkPolicy，這裏能夠得到一些策略配置的示例。

PodSecurityPolicy

PSP 是 K8s 原生的集羣維度的資源模型，它能夠在apiserver中pod建立請求的 admission 階段校驗其運行時刻行爲是否知足對應 PSP 策略的約束，好比檢查 pod 是否使用了 host 的網絡、文件系統、指定端口、PID namespace 等，同時能夠限制租戶內的用戶開啓特權（privileged）容器，限制掛盤類型，強制只讀掛載等能力；不只如此，PSP 還能夠基於綁定的策略給 pod 添加對應的 SecurityContext，包括容器運行時刻的 uid，gid 和添加或刪除的內核 capabilities 等多種設置。

關於如何開啓 PSP admission 和相關策略及權限綁定的使用，能夠參閱這裏。

OPA

OPA（Open Policy Agent）是一種功能強大的策略引擎，支持解耦式的 policy decisions 服務而且社區已經有了相對成熟的與 Kubernetes 的集成方案。當現有 RBAC 在命名空間粒度的隔離不可以知足企業應用複雜的安全需求時，能夠經過 OPA 提供 object 模型級別的細粒度訪問策略控制。

同時 OPA 支持七層的 NetworkPolicy 策略定義及基於 labels/annotation 的跨命名空間訪問控制，能夠做爲 K8s 原生 NetworkPolicy 的有效加強。

資源調度相關

Resource Quotas & Limit Range

在多租戶場景下，不一樣團隊或部門共享集羣資源，不免會有資源競爭的狀況發生，爲此咱們須要對每一個租戶的資源使用配額作出限制。其中 ResourceQuota 用於限制租戶對應命名空間下全部 pod 佔用的總資源 request 和 limit，LimitRange 用來設置租戶對應命名空間中部署 pod 的默認資源 request 和 limit 值。另外咱們還能夠對租戶的存儲資源配額和對象數量配額進行限制。

關於資源配額的詳細指導能夠參見這裏。

Pod Priority/Preemption

從 1.14 版本開始 pod 的優先級和搶佔已經從 beta 成爲穩定特性，其中 pod priority 標識了 pod 在 pending 狀態的調度隊列中等待的優先級；而當節點資源不足等緣由形成高優先的 pod 沒法被調度時，scheduler 會嘗試驅逐低優先級的 pod 來保證高優先級 pod 能夠被調度部署。

在多租戶場景下，能夠經過優先級和搶佔設置確保租戶內重要業務應用的可用性；同時 pod priority 能夠和 ResouceQuota 配合使用，完成租戶在指定優先級下有多少配額的限制。

Dedicated Nodes

注意：惡意租戶能夠規避由節點污點和容忍機制強制執行的策略。如下說明僅用於企業內部受信任租戶集羣，或租戶沒法直接訪問 Kubernetes 控制平面的集羣。

經過對集羣中的某些節點添加污點，能夠將這些節點用於指定幾個租戶專門使用。在多租戶場景下，例如集羣中的 GPU 節點能夠經過污點的方式保留給業務應用中須要使用到 GPU 的服務團隊使用。集羣管理員能夠經過如 effect: "NoSchedule" 這樣的標籤給節點添加污點，同時只有配置了相應容忍設置的 pod 能夠被調度到該節點上。

固然惡意租戶能夠一樣經過給自身 pod 添加一樣的容忍配置來訪問該節點，所以僅使用節點污點和容忍機制還沒法在非受信的多租集羣上保證目標節點的獨佔性。

關於如何使用節點污點機制來控制調度，請參閱這裏。

敏感信息保護

secrets encryption at REST

在多租戶集羣中不一樣租戶用戶共享同一套 etcd 存儲，在最終用戶能夠訪問 Kubernetes 控制平面的場景下，咱們須要保護 secrets 中的數據，避免在訪問控制策略配置不當狀況下的敏感信息泄露。爲此能夠參考 K8s 原生的 secret 加密能力，請參閱這裏。

ACK 也提供了基於阿里雲 KMS 服務的 secrets 加密開源解決方案，能夠參閱這裏。

總結

在實施多租戶架構時首先須要肯定對應的應用場景，包括判斷租戶內用戶和應用負載的可信程度以及對應的安全隔離程度。在此基礎上如下幾點是安全隔離的基本需求：

• 開啓 Kubernetes 集羣的默認安全配置：開啓 RBAC 鑑權並實現基於namespace的軟隔離；開啓 secrets encryption 能力，加強敏感信息保護；基於 CIS Kubernetes benchmarks 進行相應的安全配置；
• 開啓 NodeRestriction， AlwaysPullImages, PodSecurityPolicy 等相關 admission controllers；
• 經過 PSP 限制 pod 部署的特權模式，同時控制其運行時刻 SecurityContext；
• 配置 NetworkPolicy；
• 使用Resource Quota & Limit Range限制租戶的資源使用配額；
• 在應用運行時刻遵循權限的最小化原則，儘量縮小pod內容器的系統權限；
• Log everything；
• 對接監控系統，實現容器應用維度的監控。

而對於如 SaaS、KaaS 等服務模型下，或者咱們沒法保證租戶內用戶的可信程度時，咱們須要採起一些更強有力的隔離手段，好比：

• 使用如 OPA 等動態策略引擎進行網絡或 Object 級別的細粒度訪問控制；
• 使用安全容器實現容器運行時刻內核級別的安全隔離；
• 完備的監控、日誌、存儲等服務的多租隔離方案。

注意：文中圖片來源。

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」