溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
作者 |?匡大虎? 阿里巴巴技術專家
導讀：如何解決多租戶集群的安全隔離問題是企業上云的一個關鍵問題，本文主要介紹 Kubernetes 多租戶集群的基本概念和常見應用形態，以及在企業內部共享集群的業務場景下，基于 Kubernetes 原生和 ACK 集群現有安全管理能力快速實現多租戶集群的相關方案。
這里首先介紹一下"租戶"，租戶的概念不止局限于集群的用戶，它可以包含為一組計算，網絡，存儲等資源組成的工作負載集合。而在多租戶集群中，需要在一個集群范圍內（未來可能會是多集群）對不同的租戶提供盡可能的安全隔離，以最大程度的避免惡意租戶對其他租戶的***，同時需要保證租戶之間公平地分配共享集群資源。
在隔離的安全程度上，我們可以將其分為軟隔離 (Soft Multi-tenancy) 和硬隔離 (Hard Multi-tenancy) 兩種。
關于多租戶的不同應用場景，在下節會有更細致的介紹。
下面介紹一下典型的兩種企業多租戶應用場景和不同的隔離需求：
該場景下集群的所有用戶均來自企業內部，這也是當前很多 K8s 集群客戶的使用模式，因為服務使用者身份的可控性，相對來說這種業務形態的安全風險是相對可控的，畢竟老板可以直接裁掉不懷好意的員工：）根據企業內部人員結構的復雜程度，我們可以通過命名空間對不同部門或團隊進行資源的邏輯隔離，同時定義以下幾種角色的業務人員：
在建立了基于用戶角色的訪問控制基礎上，我們還需要保證命名空間之間的網絡隔離，在不同的命名空間之間只能夠允許白名單范圍內的跨租戶應用請求。
另外，對于業務安全等級要求較高的應用場景，我們需要限制應用容器的內核能力，可以配合 seccomp / AppArmor / SELinux 等策略工具達到限制容器運行時刻 capabilities 的目的。
當然 Kubernetes 現有的命名空間單層邏輯隔離還不足以滿足一部分大型企業應用復雜業務模型對隔離需求，我們可以關注?Virtual Cluster，它通過抽象出更高級別的租戶資源模型來實現更精細化的多租管理，以此彌補原生命名空間能力上的不足。
在 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 原生安全能力的多租戶實踐。
ACK 集群的授權分為 RAM 授權和 RBAC 授權兩個步驟，其中 RAM 授權作用于集群管理接口的訪問控制，包括對集群的 CRUD 權限（如集群可見性、擴縮容、添加節點等操作），而 RBAC 授權用于集群內部 Kubernetes 資源模型的訪問控制，可以做到指定資源在命名空間粒度的細化授權。
ACK 授權管理為租戶內用戶提供了不同級別的預置角色模板，同時支持綁定多個用戶自定義的集群角色，此外支持對批量用戶的授權。如需詳細了解 ACK 上集群相關訪問控制授權，請參閱相關幫助文檔。
NetworkPolicy 可以控制不同租戶業務 pod 之間的網絡流量，另外可以通過白名單的方式打開跨租戶之間的業務訪問限制。
您可以在使用了 Terway 網絡插件的容器服務集群上配置 NetworkPolicy，這里可以獲得一些策略配置的示例。
PSP 是 K8s 原生的集群維度的資源模型，它可以在apiserver中pod創建請求的 admission 階段校驗其運行時刻行為是否滿足對應 PSP 策略的約束，比如檢查 pod 是否使用了 host 的網絡、文件系統、指定端口、PID namespace 等，同時可以限制租戶內的用戶開啟特權（privileged）容器，限制掛盤類型，強制只讀掛載等能力；不僅如此，PSP 還可以基于綁定的策略給 pod 添加對應的 SecurityContext，包括容器運行時刻的 uid，gid 和添加或刪除的內核 capabilities 等多種設置。
關于如何開啟 PSP admission 和相關策略及權限綁定的使用，可以參閱這里。
OPA（Open Policy Agent）是一種功能強大的策略引擎，支持解耦式的 policy decisions 服務并且社區已經有了相對成熟的與 Kubernetes 的集成方案。當現有 RBAC 在命名空間粒度的隔離不能夠滿足企業應用復雜的安全需求時，可以通過 OPA 提供 object 模型級別的細粒度訪問策略控制。
同時 OPA 支持七層的 NetworkPolicy 策略定義及基于 labels/annotation 的跨命名空間訪問控制，可以作為 K8s 原生 NetworkPolicy 的有效增強。
在多租戶場景下，不同團隊或部門共享集群資源，難免會有資源競爭的情況發生，為此我們需要對每個租戶的資源使用配額做出限制。其中 ResourceQuota 用于限制租戶對應命名空間下所有 pod 占用的總資源 request 和 limit，LimitRange 用來設置租戶對應命名空間中部署 pod 的默認資源 request 和 limit 值。另外我們還可以對租戶的存儲資源配額和對象數量配額進行限制。
關于資源配額的詳細指導可以參見這里。
從 1.14 版本開始 pod 的優先級和搶占已經從 beta 成為穩定特性，其中 pod priority 標識了 pod 在 pending 狀態的調度隊列中等待的優先級；而當節點資源不足等原因造成高優先的 pod 無法被調度時，scheduler 會嘗試驅逐低優先級的 pod 來保證高優先級 pod 可以被調度部署。
在多租戶場景下，可以通過優先級和搶占設置確保租戶內重要業務應用的可用性；同時 pod priority 可以和 ResouceQuota 配合使用，完成租戶在指定優先級下有多少配額的限制。
注意：惡意租戶可以規避由節點污點和容忍機制強制執行的策略。以下說明僅用于企業內部受信任租戶集群，或租戶無法直接訪問 Kubernetes 控制平面的集群。
通過對集群中的某些節點添加污點，可以將這些節點用于指定幾個租戶專門使用。在多租戶場景下，例如集群中的 GPU 節點可以通過污點的方式保留給業務應用中需要使用到 GPU 的服務團隊使用。集群管理員可以通過如 effect: "NoSchedule" 這樣的標簽給節點添加污點，同時只有配置了相應容忍設置的 pod 可以被調度到該節點上。
當然惡意租戶可以同樣通過給自身 pod 添加同樣的容忍配置來訪問該節點，因此僅使用節點污點和容忍機制還無法在非受信的多租集群上保證目標節點的獨占性。
關于如何使用節點污點機制來控制調度，請參閱這里。
在多租戶集群中不同租戶用戶共享同一套 etcd 存儲，在最終用戶可以訪問 Kubernetes 控制平面的場景下，我們需要保護 secrets 中的數據，避免在訪問控制策略配置不當情況下的敏感信息泄露。為此可以參考 K8s 原生的 secret 加密能力，請參閱這里。
ACK 也提供了基于阿里云 KMS 服務的 secrets 加密開源解決方案，可以參閱這里。
在實施多租戶架構時首先需要確定對應的應用場景，包括判斷租戶內用戶和應用負載的可信程度以及對應的安全隔離程度。在此基礎上以下幾點是安全隔離的基本需求：
而對于如 SaaS、KaaS 等服務模型下，或者我們無法保證租戶內用戶的可信程度時，我們需要采取一些更強有力的隔離手段，比如：
注意：文中圖片來源。
“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術圈。”
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
