在接下来的描述中,将用到的符号如表1所示。

表1

表1

表1 符合及其解释 符号 解释 PermListW 一个MapReduce作业所需要的访问权限列表 ExpTime 过期时间 PK Hadoop平台内部CA公钥 SK Hadoop平台内部CA私钥 PKJ MapReduce作业所使用的公钥 SKJ MapReduce作业所使用的私钥 ID-CAPJ MapReduce作业的capability <msg>SK 由私钥SK签名的消息

表1 符合及其解释

基于Capability的访问控制方案在文[1-2]已有描述。一个Capability可以看作用户访问权限的集合。一个经典的Capability可以表示为如下的一个二元组:

(PermList,Random)

其中:

1) PermList={(Object, Permissions)}。对于一个经典文件系统的PermList来说, Object通常为树状结构,如目录或文件路径。Permissions为Read, Write, eXecutable。举例来说, PermList的值可以为: {(“/home/admin/”, RW), (“/home/data/1.txt”, R), (“/usr/sbin/ping”, X)}。如何定义一个Object的格式是与具体服务相关的,比如在Hadoop平台中,可以使用(“hdfs: /home/admin/”, RW)来表示允许读写访问HDFS文件系统中的 “/home/admin/”目录及该目录下的所有子目录及文件,还可以使用(“mr: /alice/job1”, R)来表示允许读取MapReduce用户alice的作业job1的运行状态。

2) Random是一个用于抗伪造攻击的随机数,其典型实现是数字签名(digital signature)或消息认证码(message authentication code)。

关于Capability的历史研究较多^{[3,4,5,6,7,8]}。Capability访问控制的显著特征是执行权限检查时性能高。当Capability随请求一起传递给Server时, Capability可以在本地进行验证,而无需与第三方交互(比如,不需要访问任何权限数据库)。而基于ACL访问控制列表的方法则需要访问权限中心数据库,或者需要昂贵的分布式缓存服务。Capability的另一个特征是能更有效地支持最小授权原则,它是取得系统安全性和稳定性的基础。当部分安全功能遭受攻击时,该原则能将安全风险控制到最小。Capability的这些特点使其更适合于分布式计算环境。

然而,经典Capability系统有一个主要的不足——拥有访问能力即拥有授权能力。这就是说,一个Capability可以被复制并传递给其他安全域的用户使用。Boebert在文[7]中指出,经典的Capability系统不能实施BLP模型中的 *-property^[8], 或者说无法解决confinement问题^[9]。由于经典Capability所存在的安全问题,它不能被直接用于跨域的分布式计算环境。

在Hadoop分布式环境中, Hadoop MapReduce安全框架以及HDFS服务运行在高安全层级,而用户提交的MapReduce job则运行于低安全层级。这意味着Hadoop环境涉及到至少2个安全域。因此,经典的Capability方案直接用于Hadoop环境是不安全的。为了解决这个问题,经典Capability的语义需要被扩充,比如增加主体身份信息,这就是下文提出的基于身份的Capability方案。

ID-CAP (identity-based capability)是经典Capability的一种扩展。与经典Capability相比, ID-CAP包含了更多的安全属性,如持有人身份,持有人的公钥。形式地, ID-CAP是如下属性的一个数字签名:

ID-CAP=(ID,OwnerID,OwnerPK,Type,ExpTime,PermList)SK.

其中,每项含义如下:

1) ID: ID-CAP的ID。

2) OwnerID: Capability持有者的用户ID。

3) OwnerPK: Capability持有者的认证公钥。

4) Type: Capability的类型定义,比如bearer|renewable。

5) ExpTime: Capability的过期时间。

ID-CAP可看作一种特殊的支持访问控制属性的身份证书。基于ID-CAP, 验证者可以获得持有人的公钥及其访问权限。此外, ID-CAP持有者可以是用户,也可以是作业进程。在本文的方案设计中, Capability持有人是指作业进程。

2.3.1 产生ID-CAP

ID-CAP只能由云计算平台的内部CA中心签发。此时,内部CA中心提供的仅仅是一个数字签名服务。内部CA中心可以提供一个数字签名服务的API接口和访问控制功能,供其他服务器调用。

2.3.2 验证ID-CAP

ID-CAP一般为消息请求中的参数之一。一个Client请求访问Server时,必须使用支持ID-CAP的服务接口。当Server收到消息请求时,首先要检查ID-CAP的有效性,步骤如下:

1) 验证数字签名的有效性;

2) 验证有效期;

3) 验证Type.Bearer属性是否有被设置,若有设置则进入下一步; 否则,需要验证ID-CAP持有人的身份: 根据ID-CAP中的公钥OwnerPK来进一步验证消息请求的数字签名的有效性;

4) 根据ID-CAP中的PermList来判断是否包含本次请求所需要的访问权限,若满足,则权限检查通过; 否则,权限检查失败。

2.3.3 撤销ID-CAP

ID-CAP可以通过CRL撤销列表机制被撤销,也可以支持自动撤销。CRL撤销列表可以参考PKI体系的证书撤销方法。对于自动撤销来说,当ExpTime到来时, ID-CAP将自动失效。如果一个作业的运行时间超过ExpTime, ID-CAP的Type.Renewable属性需要被设置。当Type.Renewable被设置时,在ExpTime到来之前,可以换取一个拥有更长的过期时间的ID-CAP。

Hadoop作为云计算服务的一个底层平台框架,本文的设计基于以下考虑:

1) 最小授权原则。这一原则是提高分布式系统安全性和稳定性的核心。从容错和抵制恶意攻击的角度来看,实施最小权限可以有效的加强数据保护。在Hadoop系统中,本文的目标是让每一个作业都以最小权限运行。

2) 作业级隔离。在原生Hadoop系统中,一个用户提交的所有作业都具有相同的访问权限,而且只能做到用户级别的隔离,而无法满足作业级的隔离。那么,一个作业如果遭受攻击或遇到错误,很容易殃及该用户的所有作业。

3) 高性能。在云计算系统中,性能往往是所追求的一个核心指标。解依赖是提高性能的一个常用方法,尤其是高频操作一定不能依赖于某个单点。比如,权限检查操作就是一个高频操作,就要做到不依赖于单点服务(比如,不应该与权限数据库服务进行交互)。

在本文的方案中,除了MapReduce和HDFS服务之外,需要有一个内部CA服务和一个Broker服务。CA服务主要提供各服务模块及用户作业的密钥颁发和ID-CAP颁发服务。Broker服务主要提供用户的接入。

3.2.1 平台启动

在部署启动Hadoop集群之前,需要确保CA服务正常工作。首先为Hadoop各个Server (eg, MapReduce, HDFS, ZooKeeper) 申请Server PK/SK以及各自的ID-CAP。若是第一次部署或部署选项中显式要求更新密钥对和ID-CAP, 那么CA会撤销Server上一次使用的有效ID-CAP, 并为各个Server创建一个随机的Server PK/SK密钥对; 若是重启集群并无需更新密钥对和ID-CAP, 那么CA会继续保留Server正在使用的密钥对和ID-CAP。部署成功后, MapReduce的JobTracker和TaskTrackers都会获得相同的ID-CAP_T和(PK_T,SK_T), HDFS的NameNode和DataNodes则会获得相同的ID-CAP_N和(PK_N,SK_N)。

然后,申请Broker Server的PK/SK和ID-CAP, 申请方式与其他模块类似。部署成功后, Broker Server将会获得自己的ID-CAP_B和(PK_B,SK_B)。

3.2.2 作业提交

Hadoop平台服务启动之后,用户就可以提交MapReduce作业了。图1描述了作业提交的流程。

图1

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图1 提交一个MapReduce作业

在图1中, Client位于Hadoop平台的外面,其他组件属于平台的内部模块。Broker是整个Hadoop平台的入口,它执行用户身份认证与权限检查逻辑。CA是整个Hadoop平台的密钥管理中心,负责密钥及ID-CAP的颁发。JobTracker和TaskTracker为Hadoop MapReduce框架内组件,负责执行用户提交的MapReduce作业。

下面详细描述执行流程:

Step 1 Client通过外部认证之后, Client向Broker提交作业请求,请求内容包括:

(Client’s identity proof,JobExecutable,JobConfiguration)

由于Hadoop不做用户管理与认证, Client需要进行外部认证,比如Kerberos SSO认证服务登录,此时Client获得的身份证明就是一个访问Broker的Kerberos ST。当Broker收到请求后,首先验证Client的认证凭据,确认Client的用户身份,获得uid。分析作业配置文件JobConfiguration, 获取此作业需要访问的HDFS文件资源及其访问权限currentPermList。查询用户权限数据,确保currentPermList是该用户的permList的一个子集,否则返回权限检查失败的出错信息。

Step 2 Broker向CA申请颁发该job的ID-CAP _J。该请求内容为:

(ID-CAPB,(uid,currentPermList,Type,ExpTime)SK,B).

其中ID-CAP_B是Broker在初始化时获取的Capability, 可以用于访问CA和JobTracker的部分API。SK_B是Broker的私钥,用于数字签名。

Step 3 当CA收到颁发ID-CAP_J的请求时,首先验证请求者的身份是否为Broker, 这是通过验证请求的数字签名来完成的。然后验证ID-CAP_B来检查请求者的访问权限。验证通过后,为该Job产生一个公私钥对(PK_J,SK_J), 根据PK_J、 uid、 currentPermList、 Type、 ExpTime等请求参数,产生如下的ID-CAP_J:

ID-CAPJ=(ID,uid,PKJ,Type,ExpTime,currentPermList)SK.

最后, CA将SK_J和ID-CAP_J返回给Broker。

Step 4 收到CA返回的SK_J和ID-CAP_J之后, Borker将作业SK_J和ID-CAP_J添加到JobConfiguration, 向JobTracker提交SubmitJob请求时需要传递如下参数:

(ID-CAPB,(Request)SK,B).

JobTracker收到请求后,首先验证Request的数字签名,然后验证ID-CAP_B的有效性及其访问权限。验证通过后,从Request中提取JobConfiguration, 然后解析该job运行时所需要的SK_J和ID-CAP_J, 并传递给TaskTracker。

3.2.3 作业进程访问HDFS

TaskTracker启动job工作进程,会为工作进程配置好SK_J和ID-CAP_J。当job工作进程需要访问HDFS时,访问控制的执行流程如图2所示。

图2

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图2 作业进程访问HDFS

作业进程以一个HDFS Client角色与HDFS通信。假设Client执行文件读操作,比如读文件hdfs: /data/file1.txt, 下面来看具体的执行流程。

Step 1 Client向NameNode提交OpenFileForRead请求时,需要传递如下参数:

(ID-CAPJ,(Request)SK,J).

Step 2 NameNode验证Request的数字签名是否有效,然后验证ID-CAP_J是否有对/data/file1.txt的读权限; 若没有读权限,则拒绝。验证通过后, NameNode向Client发送文件位置信息,如DataNode位置, BlockInfo, 并且还包含一个访问DataNode的token。此token为bearer类型, DataNode无需验证持有人的身份,任何Client持有该token都可以访问DataNode。产生token方法如下:

token=HMAC_SHA1(SKN,OwnerIDBlockInfoExpTime).

Step 3 Client向DataNode发送读数据请求,请求参数需要包含步骤2中接收到的token。

Step 4 DataNode验证token的有效性,验证通过后,返回相应的数据块。

3.2.4 Master-Slaves认证

在Hadoop内部, MapReduce和HDFS都可以看做是一种Master-Slaves结构,比如JobTracker-TaskTrackers、 NameNode-DataNodes。在系统启动时, JobTracker与TaskTrackers都获得了私钥SK_T, NameNode与DataNodes也都获得了私钥SK_N。基于共享的私钥, Master与Slaves按如下方法进行认证: 将共享的私钥作为MasterKey, 使用HMAC_SHA1来计算消息签名,从而实现Master与Slaves之间通信的可认证性。

基于Hadoop的云计算平台主要提供数据分析与处理服务。Hadoop用户直接提交的或上层应用程序提交的MapReduce作业通常在一层或多层沙箱里运行。在第2节的威胁模型中,假设沙箱机制是安全的,那么恶意的MapReduce程序就无法控制底层操作系统,无法监听或篡改集群中传输的网络数据包。

4.1.1 认证性

1) Hadoop集群内部各模块之间的消息通信是可认证的。在job提交阶段(见3.2.2节描述), 每一个消息通信都有请求者的数字签名。运行在沙箱中的恶意程序无法获取其他作业进程的签名密钥,所以无法伪造消息请求者的身份。在job运行阶段(见3.2.3节描述), 当Client使用token来访问DataNode时, DataNode能验证token的真实性。由于token是NameNode使用HMAC计算的,所使用的是DataNode与NameNode之间所共享的密钥SK_N, 运行在沙箱中的恶意作业进程无法窃取到SK_N, 所以无法伪造token。

2) Hadoop集群内部各模块内部的消息通信是可认证的。如3.2.4节所描述, Master与Slaves之间的通信都是基于共享的密钥来计算HMAC来完成消息认证的,所以无法伪造消息请求者的身份。

4.1.2 作业级的最小权限控制

每个用户都有一个最大的权限集合,它由Broker服务所管理。在原生Hadoop中,用户提交的每个job都使用该用户的最大权限来执行。在本文的方案中, Broker会根据每个job的输入和输出配置来产生一个带有效期限的ID-CAP, 其访问权限是用户权限集合的一个子集,这个权限子集只满足运行该job所需要的权限,而不会多出与该运行job无关的权限。

追求高性能是本方案设计的一个基本原则。为了验证这一方案的有效性,本文基于Hadoop-1.0.2开发了一个概念证明系统。影响该方案性能的一个最大因素是密码函数操作。在所有的密码函数操作中,开销最大的是签发Capability操作,因为它涉及到计算数字签名操作。但是由于Hadoop平台主要用于离线数据处理业务,作业的提交并不是一个频繁的操作,所以签发Capability不会成为瓶颈,所以它并不是性能优化的目标。密码操作的优化目标应该是Capability验证操作,因为这是一个相当频繁的操作。鉴于此,选择数字签名算法时,尽管计算ECC签名要比RSA签名高效很多,但验证RSA签名的性能却要显著优于ECC签名。因此本文选择了RSA数字签名方案。实验中,采用了1 024-bit RSA签名算法(参考PKCS#1 v2.1), 该方案中选择RSA公钥指数 e=3, 签名验证操作仅需2次模乘运算。实验证明密码操作所引入的计算开销是可忽略的。

4.2.1 集群配置

实验环境使用1台物理主机和9台KVM虚拟主机。NameNode, JobTracker共享物理主机, DataNodes和TaskTrackers使用虚拟机。物理主机配置: CPU 2.53 GHz, 24 Cores, 96 G内存, 2×512 G 磁盘空间; 基于Linux的KVM(Kernel-based Virtual Machine)虚拟机配置: CPU 2.53 GHz, 6 Cores, 10 G内存, 100 G磁盘空间。此外,每个节点上使用的Linux版本为RHEL6.2, 2.6.32-220.el6.x86_64, Hadoop版本为Hadoop-1.0.2。

4.2.2 Hadoop基准测试

考虑到Hadoop平台主要提供大规模离线数据处理业务,用户一般主要关注的几个基准测试包括: HDFS读写测试、排序测试和MapReduce连续性测试。下面就这3个基准测试做了性能对比。

1) HDFS读写测试

执行读测试和写测试的工具如下:

$ hadoop jar hadoop-test-1.0.2.jar TestDFSIO -read -nrFiles 10 -fileSize 1 000.

$ hadoop jar hadoop-test-1.0.2.jar TestDFSIO -write -nrFiles 10 -fileSize 1 000.

基于原生Hadoop和基于本文提出的ID-CAP方案的吞吐量和平均IO率的测试结果如表2所示。容易看出, ID-CAP方案并没有导致吞吐量和平均IO率的显著降低。

表2

表2

表2 HDFS读写测试 方案类型 操作类型 ThroughputMB·s-1 Average IO rateMB·s-1 原生Hadoop Read 39.82 42.02 Write 18.82 19.23 ID-CAP based Read 39.17 41.43 Write 18.02 18.38

表2 HDFS读写测试

2) 排序测试

每个节点运行10个map任务,产生10 GB的随机二进制数据。测试工具如下:

$ hadoop jar hadoop-examples-1.0.2.jar randomwriter /benchmarks/random-data.

排序的测试工具如下:

$ hadoop jar hadoop-examples-1.0.2.jar sort /benchmarks/random-data /benchmarks/sorted-data.

排序正确性检查的测试工具如下:

$ hadoop jar hadoop-test-1.0.2.jar testmapredsort -sortInput /benchmarks/random-data -sortOutput /benchmarks/sorted-data.

基于原生Hadoop和基于本文提出的ID-CAP方案在这3个步骤的运行时间对比结果如表3所示。测试结果显示, ID-CAP方案对排序测试没有明显的性能下降。

表3

表3

表3 排序测试 测试目标 原生 Hadoop/s ID-CAP based Hadoop/s 生产随机数据MapReduce (map: 90, reduce: 0) 877 880 排序MapReduce (map: 720, reduce: 48) 5 655 5 663 排序正确性检查MapReduce (map: 138, reduce: 1) 865 867

表3 排序测试

3) MapReduce连续性测试

每个job处理10 000行文本文件、 6个map、 2个reduce、 只收集数据,分别运行100次,测试工具如下:

$ hadoop jar hadoop-test-1.0.2.jar mrbench -numRuns 100 -maps 6 -reduces 2 -inputLines 10 000.

基于原生Hadoop和基于本文提出的ID-CAP方案的平均执行时间对比结果如表4所示。测试结果显示, ID-CAP方案对MapReduce连续性测试并没有明显的性能下降。

表4

表4

表4 MapReduce连续性测试 测试次数 原生Hadoop AvgTime/μs ID-CAP based Hadoop AvgTime/μs numRuns=100 31 413 33 047

表4 MapReduce连续性测试