摘要：摘要在年云棲大會北京峰會的大數據專場中，來自阿里云的高級技術專家李雪峰帶來了主題為金融級別大數據平臺的多租戶隔離實踐的演講。三是運行隔離機制。針對這一問題，提供了多層隔離嵌套方案以便規避這種潛在的安全風險。

摘要：在2017年云棲大會?北京峰會的大數據專場中，來自阿里云的高級技術專家李雪峰帶來了主題為《金融級別大數據平臺的多租戶隔離實踐》的演講。在分享中，李雪峰首先介紹了基于傳統IaaS單租戶架構做隔離時面臨的問題；然后，他重點分享了MaxCompute PaaS層面的多租戶的架構以及MaxCompute在安全隔離方面的具體實踐。
點此查看原文：http://click.aliyun.com/m/42755/

在2017年云棲大會?北京峰會的大數據專場中，來自阿里云的高級技術專家李雪峰帶來了主題為《金融級別大數據平臺的多租戶隔離實踐》的演講。在分享中，李雪峰首先介紹了基于傳統IaaS單租戶架構做隔離時面臨的問題；然后，他重點分享了MaxCompute PaaS層面的多租戶的架構以及MaxCompute在安全隔離方面的具體實踐。

IaaS單租戶大數據產品架構

基于IaaS單租戶大數據產品架構如上圖所示，架構底層通常利用HDFS2實現；基于HDFS2之上搭建Hadoop Yarn或MESOS等資源管控平臺；在其之上再實現具體的計算模型，如MR、Hive、HBASE以及Spark等。在這類生態環境中，IaaS平臺通常作為同一租戶存在，當用戶產生新需求時，通過IaaS平臺申請一批集群（虛機），再這些集群上部署相應的開源產品。從隔離的角度出發，這種生態面臨以下問題：

首先，IaaS單租戶大數據產品架構在實際使用時存在一定的邏輯問題。使用者進行數據分析時，需要了解使用的每種產品的具體邏輯，例如運行SQL時，需要理解Hive的邏輯，使用Spark時，需要學習spark的相關知識。當使用產品數量較少時，使用成本還能夠得到有效控制；當需要多種產品相互協助使用時，學習成本便成幾何倍數增加。并且，通常兩款不同的開源產品之間的邏輯模型相互間無法識別，當遇到鑒權等問題時，邏輯問題更加突出。

其次，每一種開源產品在運行級別上都有其自身的優先級定義。在使用同一種開源產品時，任務的優先級會按照開源產品自身的優先級體系進行運行，高優先級的任務會比低優先級的任務得到更多的資源，運行的時長也會得到更好地保障。當同時使用多款開源產品時，基于IaaS單租戶大數據產品架構無法做到運行優先級的全局最優化。

最后，上述這些開源產品通常會提供用戶自定義邏輯，例如MR或Hive提供的UDF。當用戶自定義的代碼在大數據產品內運行時，會造成一定的安全風險。例如，Hadoop Yarn在運行用戶自定義代碼時，僅僅使用比較簡單的Linux Container機制進行隔離。使用這種機制運行隔離時，用戶的代碼邏輯和Hadoop自身進程是運行在同一個內核（kernel）下的，也就是說如果這部分用戶代碼邏輯包含的攻擊程序能夠影響機器kernel，則在同一個內核下運行的大數據產品進程也會隨之受到影響。通常情況下，大數據產品的一個Job會根據數據分片的大小同時運行在集群的大部分機器、甚至所有機器上。這種情況下，安全的風險便放大至整個集群。一種極端的情況是：當利用一個內核的漏洞攻擊一臺機器成功時，當所提交的Job分片足夠大時，可能會使得整個計算集群癱瘓。

在認識到上述問題之后，MaxCompute通過獨立自研整體系統架構，提供了PaaS層面的多租戶能力。

MaxCompute PaaS多租戶架構

上圖是MaxCompute PaaS多租戶架構示意圖。從圖中可以看出，MaxCompute運行在飛天操作系統上，依賴于飛天伏羲模塊提供統一資源管控；依賴于飛天盤古模塊提供統一存儲；依賴于飛天女媧模塊提供一致性服務。MaxCompute通過提供同一套計算引擎為上層提供了多種計算形態，包括SQL、MR、圖計算、PAI、準實時等。

目前，這套計算引擎已經為金融用戶在公共云上提供了相應的計算能力。

在解決MaxCompute多租戶這一問題時，主要是從三個角度入手：

一是邏輯隔離。從租戶的角度出發，每個租戶都有自己獨立的邏輯模型，擁有自己獨立的資源以及基于相同的邏輯模型實現的統一授權模型。

二是資源隔離。對于不同租戶的任務，在MaxCompute運行時，能夠實現統一的、全局最優的任務調度能力以及資源隔離能力。

三是運行隔離機制。目前，MaxCompute提供了用戶自定義邏輯的功能（如Python UDF），為用戶自定義邏輯在MaxCompute上運行提供了一套完善的運行隔離機制。

下面來具體分析下MaxCompute提供的這三種隔離機制。

MaxCompute 邏輯隔離

目前，對于同一個MaxCompute實例，無論其運行在多少個物理集群上，都能在邏輯層提供統一的租戶體系。對于這套租戶體系，同一個租戶的數據資源視圖和權限管理模型是唯一的，并與租戶模型綁定。在實際使用中，MaxCompute上的租戶對應于MaxCompute的Project，其中Project包含租戶所有的資源、屬性以及權限等信息。

如上圖所示，Project由屬性（Properties）、主題（Subject）、實體（Object）三部分組成。其中屬性包括Quota、Owner、Payment Account、Region等信息；在Project內部所有的授權訪問都需要以User ID為主題，基于這些主題，MaxCompute提供了角色模型用于實現授權聚集；上文所提到的計算模型（MR、Hive等）要操作的資源最終都落腳于Project中的某一實體上，例如SQL模型對應于Table實體、UDF對應Function實體。

基于以上提供的邏輯模型，MaxCompute提供了一套完整的鑒權、授權機制用于管控權限。首先，所有權限均來源于Project Ower，作為Project的所有者，它擁有該Project內的全部權限，任何用戶使用該Project進行計算時，首先需要Project Owner對其進行授權（具體實現是利用GTANT語句）；當該用戶訪問Project時，它會以User ID的身份進行讀寫表、創建函數、添加刪除資源等操作；這些操作被真正執行之前，會通過統一的ACL邏輯對當前User ID是否具有相應的權限進行判斷。

上圖給出了MaxCompute對不同類型對象支持的操作方式，更多詳細操作說明請參考官方文檔。

MaxCompute 資源隔離

MaxCompute 的計算引擎依賴于飛天操作系統提供資源運行、隔離能力。

如上圖所示，當不同任務Job-0、Job-n 提交到飛天伏羲模塊時，伏羲的調度系統會根據不用用戶的運行級別來分配任務的運行級別，這與上文提到的Project中的屬性相對應。伏羲模塊將不同的任務Job-0、Job-n轉化為伏羲任務；然后調度到計算集群的節點上；最終在計算集群上，同一個server上會同時運行多個租戶的任務，這些任務均以伏羲Worker形態運行。

對于其中的一臺機器，當該機器上的伏羲引擎收到Worker Plan后，它會根據Worker所對應用戶的quota值去配置當前這臺機器上的Cgroup的參數。這樣一來，就保證不同用戶提交的Job最終在物理機上運行的Cgroup配置參數不同。目前，MaxCompute依賴于Linux Kernel提供的Cgroup能力來規劃某個特定進程在物理機上所得的CPU、Memory等資源。

MaxCompute 運行隔離

最后來分析下MaxCompute為了安全運行用戶自定義邏輯所提供的運行隔離機制。當伏羲運行用戶自定義代碼邏輯時，它會拉取一個隔離的環境，把用戶的代碼運行在隔離的進程中。該進程對與伏羲而言與其他進程無差別，但其運行環境是在隔離系統中；也就說對于伏羲而言，這個進程是普通的進程，但對于untrusted code進程是隔離的。

運行隔離又可以分為進程隔離、設備隔離和網絡隔離。

進程隔離

在進程隔離方面，對于單個進程而言，如果是運行的untrusted code（有可能包括惡意攻擊的代碼）進程，有可能會對計算平臺造成損害。針對這一問題，MaxCompute提供了多層隔離嵌套方案以便規避這種潛在的安全風險。在最內部，MaxCompute提供了語言級沙箱，包括java sandbox和python sandbox，這種語言級別的沙箱為用戶代碼提供了最內層的隔離，例如java UDF 目前可以做到限制加載具體的類，python UDF可以做到函數級別的限制；外面一層，MaxCompute提供了進程隔離，它依賴于當前Linux Kernel提供的內核機制實現進程的隔離，使用的內核機制包括namespace、cgroup 、secomp-bpf等；最外側，MaxCompute實現了一層輕量級的虛擬化，它的實現原理是通過深度定制Linux Kernel以及一個最小化的Hypervisor，進而提供非常輕量級的虛擬機（建立時間僅為幾百毫秒）。這樣一來，untrusted code最終會以hypervisor方式運行在物理機；也就是說，對于伏羲而言，它看到的僅僅是hypervisor的進程，但對于untrusted code，它看到的是一套隔離環境。

設備隔離

除此之外，MaxCompute也為用戶自定義代碼提供了硬件加速能力，例如PAI是支持直接GPU訪問。目前，MaxCompute通過PCIE passthrough方式將GPU卡直接passthrough到VM內部，允許guest進程直接通過PCIE總線以及guest kernel 內的GPU driver來訪問GPU。

這種VM通過PCIE總線訪問GPU的實現方式相較于在物理機直接訪問GPU，性能相近；另一方面，在物理機上無需安裝GPU driver，規避掉了GPU driver對平臺穩定性和可靠性影響。

網絡隔離

在某些產品上，MaxComputer為用戶代碼邏輯提供了網絡隔離能力。在伏羲拉起的VM之間實現了一層虛擬網絡。這些VM可以通過虛擬網絡進行直接通信，這也為在VM內部運行一些開源代碼提供了良好的兼容性。同時，從上圖可以看到，用戶自定義的代碼邏輯并不是直接訪問物理網絡的；而伏羲拉起的tursted code包括MaxCompute框架上的代碼是通過物理網絡進行通信的，這種做法保證了MaxCompute框架在通信上的低時延。

掃碼獲取更多資訊：