从单租户IaaS到多租户PaaS——金融级别大数据平台MaxCompute的多租户隔离实践

摘要：摘要在年云栖大会北京峰会的大数据专场中，来自阿里云的高级技术专家李雪峰带来了主题为金融级别大数据平台的多租户隔离实践的演讲。三是运行隔离机制。针对这一问题，提供了多层隔离嵌套方案以便规避这种潜在的安全风险。

摘要：在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框架在通信上的低时延。

扫码获取更多资讯：