Hadoop系统框架安全机制

共计 7823 个字符，预计需要花费 20 分钟才能阅读完成。

Hadoop 是开源组织 Apache 开发的一个开源分布式系统，基于谷歌发表的云计算系统理论实现。它以一种可靠、高效、可伸缩的方式，在普通计算机群上实现海量数据处理。随着越来越多的企业在 Hadoop 部署应用、存储私密数据，Hadoop 的安全问题也开始为人们所重视。Hadoop 安全框架存在不小挑战，一方面，由于 Hadoop 自身安全机制依赖 Kerberos、非对称加密的 Token 认证机制、传输加密机制、基于 Linux/Unix 系统自带的访问控制机制，在认证、访问、授权等机制存在不足；另一方面，Hadoop 一般不是独立运行，而是配合使用生态系统中的其他组件技术，这些技术在安全性上缺乏统一的安全措施。

1 Hadoop 体系架构介绍：

1.1 Hadoop 发展历史

Hadoop 建立在之前的 Google Lab 开发的 Map/Reduce 和 Google File System(GFS) 基础上，并于 2005 年作为 Lucene 的子项目 Nutch 的一部分由 Apache 基金会正式引入，在随后成为 Apache 旗下一个单独的开发项目。Hadoop 最初由 HDFS，MapReuce，Hbase 三大核心组件组成，后来发展成为包含 HDFS、MapReduce、Hbase、Hive 和 ZooKeeper 等 60 多个组件的生态系统。在 Hadoop 的工作中，Map 负责分解任务，Reduce 负责结果汇总，HDFS 负责数据的管理。在互联网领域，Hadoop 发展状况良好，脸书的数据挖掘和日志统计、推特的数据存储、百度的日志分析和网页数据库的数据挖掘等领域都使用了 Hadoop 云计算平台。

1.2 HDFS 框架介绍

HDFS 是 Hadoop 平台的分布式文件管理系统[3]，是 Hadoop 最重要的组件之一。它采用 Master/Slaver 架构对文件系统进行管理。一个 HDFS 集群一般由一个 NameNode 节点和一定数量的 DataNodes 节点组成。下面是各类节点在集群中的主要作用：

（1）NameNode 节点。NameNode 包含 HDFS 文件系统的文件目录树及文件索引目录、文件 Block 列表等进行相应的维护，并将这些信息持久化到本地磁盘的镜像文件和编辑日志中中。NameNode 负责对 HDFS 文件系统的命名空间、集群配置信息和文件 Block 块的创建、删除、复制等操作进行管理，并协调接收客户端对 HDFS 文件系统的访问请求，执行相应的文件操作，例如对文件的打开、关闭、重命名等。NameNode 将 HDFS 中的超大文件划分为多个 Block 块，存储在不同的 DataNode。

（2）DataNode 是具体任务的执行节点，存在于客户端，承担具体执行任务相关的数据及操作。DataNode 接受 Nmaenode 的统一调度，对文件的 Block 块进行创建、删除、和复制等操作，同时 DataNode 还负责接收处理客户端对文件的读 / 写请求。

（3）DataNode 与 NameNode 间的交互：NameNode 在每次启动系统时都会动态重建文件系统的元数据信息，这时它会以心跳轮询集群中的 DataNode 节点，DataNode 以心跳响应 NameNode，定时向 NameNode 发送它所存储的文件块信息。

1.3 Hadoop 的计算框架

MapReduce 是 Hadoop 的核心计算组件[4]，被设计用于并行计算海量数据。MapReduce 框架的核心步骤主要分两部分：Map 和 Reduce。当用户向 MapReduce 框架提交一个计算作业时，它会首先把计算作业拆分成若干个 Map 任务，然后分配到不同的节点上去执行，每一个 Map 任务处理输入数据中的一部分，当 Map 任务完成后，它会生成一些中间文件，这些中间文件将会作为 Reduce 任务的输入数据。Reduce 任务的主要目标就是把前面若干个 Map 的输出汇总到一起并输出。

本文主要讲解最新的 Hadoop2.x（YARN）版本（目前最新的稳定版本为 Hadoop2.7）。在 YARN 中，原先负责资源管理和作业控制功能的 JobTracker 被遗弃，功能分别由组件 ResourceManager 和 ApplicationMaster 实现。其中，ResourceManager 负责所有应用程序的资源分配，而 ApplicationMaster 仅负责管理一个应用程序。YARN 事实上转变成为一个弹性计算平台，它不仅支持 MapReduce，而且支持在线处理的 Storm，以及近几年来发展势头迅速的 Spark 等计算框架。

2 Hadoop 安全机制

一般而言，系统安全机制由认证 (authentication) 和授权 (authorization) 两大部分构成。认证就是简单地对一个实体的身份进行判断；而授权则是向实体授予对数据资源和信息访问权限的决策过程。本文也着重从这两方面展开叙述。

2.1 Hadoop 早期安全机制

Hadoop 的早期用例都是围绕着如何管理大量的公共网络数据，没有考虑保密性。早期版本假定 HDFS 和 MapReduce 集群运行在安全的内部环境中，由一组相互合作、互相信任的用户所使用，因而其访问控制措施的目标是防止偶然的数据丢失，而并非阻止非授权的数据访问，因此未对数据传输过程中的通信安全作出合理有效的防范措施。尽管在早期版本中实现了审计和授权控制（HDFS 文件许可），然而这种访问控制很容易避开，因为任何用户能轻易模拟成其他任何用户，占有其他用户的资源甚至杀死其他用户的任务。

随着 Hadoop 在大数据分析和处理上应用的日益广泛，Hadoop 开始开发健全的安全措施，并在随后选择 Kerberos 作为 Hadoop 的认证机制，并在 Hadoop 0.20 版本后采用新的安全措施：

（1）在 Hadoop RPC（Hadoop 远程过程调用协议）中添加了权限认证机制。用 Kerberos RPC (SASL/GSSAPI)来实现 Kerberos 及 RPC 连接上的用户、进程及 Hadoop 服务的相互认证。

为 HTTP Web 控制台提供“即插即用”的认证。网络应用和网络控制台的实现者可以为 HTTP 连接实现自己的认证机制，包括（但不限于）HTTP SPNEGO 认证。当用户调用 RPC 时，用户的登录名会通过 RPC 头部传递给 RPC，之后 RPC 使用简单验证安全层(Simple Authentication and Security Layer，SASL）确定一个权限协议（支持 Kerberos 和 DIGEST-MD5 两种），完成 RPC 授权。

（2）强制执行 HDFS 的文件许可。可以通过 NameNode 根据文件许可（用户及组的访问控制列表（ACLs））强制执行对 HDFS 中文件的访问控制，用于后续认证检查的委托令牌。为了降低性能开销和 Kerberos KDC 上的负载，可以在各种客户端和服务经过初始的用户认证后使用委托令牌。委托令牌用于跟 NameNode 之间的通讯，在无需 Kerberos 服务器参与的情况下完成后续的认证后访问。委托令牌的安全机制也一直延续到后续版本。

（3）用于数据访问控制的块访问令牌。当需要访问数据块时，NameNode 会根据 HDFS 的文件许可做出访问控制决策，并发出一个块访问令牌，可以把这个令牌交给 DataNode 用于块访问请求。因为 DataNode 没有文件或访问许可的概念，所以必须在 HDFS 许可和数据块的访问之间建立对接。

（4）用作业令牌强制任务授权。作业令牌确保任务只能做交给他们去做的作业。也可以把任务配置成当用户提交作业时才运行，简化访问控制检查。

进入 Hadoop2.x 版本后，Hadoop 安全机制显著提高。

2.2 Hadoop 2(YARN)的安全机制

2.2.1 Hadoop 2(YARN)的认证机制

在 Hadoop 中，客户端与 NameNode 和客户端与 ResourceManager 之间初次通信均采用了 Kerberos 进行身份认证，之后便换用委托令牌认证以较小开销，而 DataNode 与 NameNode 和 NodeManager 与 ResourceManager 之间的认证始终采用 Kerberos 机制。

接下来分别分析 Hadoop 中 Kerberos 和委托令牌的工作原理。

（1）Kerberos 认证协议。在一个分布式的 Client/Server 体系结构中，Kerberos 采用一个或多个 Kerberos 服务器提供鉴别服务。首先将需要认证的机器手动将添加 Kerberos 数据库，并在密钥分发中心和各个节点分别产生密钥表。随后客户端可以和服务器认证，也可以各个节点之间相互认证。当客户端想请求应用服务器上的资源时，首先由客户端向密钥分发中心请求一张身份证明，然后将身份证明交给应用服务器进行验证，在通过服务器的验证后，服务器就会为客户端分配所请求的资源，如图 1 所示。当节点在 Namenode 注册时，它必须提供自己的认证密钥并与服务器进行认证，防止存在外部节点冒充内部节点的情况。

Kerberos 也有几大缺点：采用对称加密机制，加密和解密使用相同的密钥，安全性有所降低；Kerberos 中身份认证服务和授权服务采用集中式管理，系统的性能和安全性也过分依赖于搭载这两个服务的服务器的性能和安全。

（2）委托令牌认证协议。

利用 Kerberos 获得最初认证后，客户端获得一个委托令牌，令牌赋予节点之间的某些权限。获得令牌后，客户端视情况将它传递给下一个在 Namenod 上的作业。任何获得令牌的用户可以模仿 NameNode 上的用户。Hadoop 中的令牌主要由下表列出的几个字段组成[5]：

TokenID = {ownerID，renewerID，issueDate，maxDate，sequenceNumber}

TokenAuthenticator = HMAC-SHA1(masterKey，TokenID)

Delegation Token = {TokenID，TokenAuthenticator}

其中关键参数如下：

最大时间（maxData）。每个令牌与一个失效时间关联，若当前时间超过失效时间，则令牌会从内存中清楚，不能再使用。

序列号（sequenceNumber）。每个令牌的产生，都会使序列号增加。

主密钥（masterKey）。主密钥由 NameNode 随机选择并只有 NameNode 知道，随后用该密钥来生成委托令牌。

默认情况下，委托令牌有效期是 1 天。作业追踪器是重建者，跟踪作业的运行情况以更新或取消令牌。由于密钥与令牌之间有一一对应关系，一个密钥产生一个令牌，因此过去 7 天内的密钥将会被保存，以便回收已经产生的令牌。

令牌赋予了拥有节点权限并保证安全，节点根据令牌种类不同而拥有不同的权限。如持有 ResourceManager 令牌的应用程序及其发起的任务可以安全地与 ResourceManager 交互。Application 令牌保证 ApplicationMaster 与 ResourceManager 之间的通信安全。

委托令牌也存在缺点：认证用户可以与未认证用户共享委托令牌，这可能造成令牌滥用。

2.2.2 Hadoop 2(YARN)的授权机制

在正式接触 YARN 授权机制之前，先介绍 HDFS 的文件访问控制机制。HDFS 的文件访问控制机制与当前 Unix 的一致，即将权限授予对象分为用户、同组用户和其他用户，且可单独为每类对象设置一个文件的读、写和可执行权限。此外，用户和用户组的关系是插拔式的，默认情况下共用 Unix/Linux 下的用户与用户组对应关系，这与 YARN 的授权设计思路是一致的。

YARN 的授权机制是通过访问控制列表（ACL）实现的。访问控制列表授权了哪些可以访问，哪些无法访问。按照授权实体，可分为作业队列访问控制列表、应用程序访问控制列表和服务访问��制列表。

(1) 作业队列访问控制列表

为了方便管理集群中的用户，YARN 将用户 / 用户组分成若干队列，并可指定每个用户 / 用户组所属的队列。在每个队列中，用户可以进行作业提交、删除等。通常而言，每个队列包含两种权限：提交应用程序权限和管理应用程序权限（比如杀死任意应用程序），这些可以通过配置文件设置。

(2) 应用程序访问控制列表

应用程序访问控制机制的设置方法是在客户端设设置对应的用户列表，这些信息传递到 ResourceManager 端后，由它维护和使用。为了用户使用方便，应用程序可对外提供一些特殊的可直接设置的参数。以 MapReduce 作业为例，用户可以为每个作业单独设置查看和修改权限。默认情况下，作业拥有者和超级用户（可配置）拥有以上两种权限且不可以修改。

(3) 服务访问控制列表

服务访问控制是 Hadoop 提供的最原始的授权机制，它用于确保只有那些经过授权的客户端才能访问对应的服务。比如可设置访问控制列表以指定哪些用户可以向集群中提交应用程序。服务访问控制是通过控制各个服务之间的通信协议实现的，它通常发生在其他访问控制机制之前，比如文件权限检查、队列权限检查等。

该授权机制的缺陷是，由于需要维护大量的访问控制列表，授权也给系统带来了不小的开销。

2.2.3 Hadoop 2(YARN)的其他安全机制

（1）加密机制

对于静态数据，Hadoop 提供两种方式进行保护：一是文件先进行加密，再存储在 Hadoop 节点中；二是一旦数据加载到 Hadoop 系统中，立即申请对数据块的加密。对于动态数据，传输进或传输出的数据，Hadoop 可以提供认证与安全层（SASL）认证进行加密。其中核心加密技术常用 MD5-DIGEST，在此基础上搭载加密的安全协议有如下三种：

a. SASL 安全协议加密

SASL 提供了 MD5-DIGEST 等可选的不同种类的保护服务，具有提供认证，保护消息数据完整性、机密性等功能。

b. HDFS 文件传输加密

HDFS 现存的数据服务协议封装了简单的认证与安全握手协议。认证后，NameNode 产生数据加密密钥并将数据信息（如数据块位置、数据块标志、访问令牌等）发送到客户端，成为 MD5-DIGEST 的凭证。

c. 安全套接层（SSL）

首先需要配置 SSL 来加密 HTTP 协议。为了避免恶意用户访问 Reduce 后的输出结果，Reduce 任务计算请求的 HMAC-SHA1，并通过作业令牌加密当前时间戳。任务追踪器将利用该 HMAC-SHA1 与请求中发送的 HMAC-SHA1。如果计算出的 HMAC-SHA1 是 URL 中的一个，任务追踪器将会相应请求。

（2）审查日志（Audit Log）

Hadoop 部署了一个日志审查监控系统，管理和报告系统变化情况。

措施：

（3）资源控制

YARN 中可以控制最低限度的网络消耗，最低限度的资源、线程、进程的消耗，来保障系统的稳定和安全性。

2.3 Hadoop 2(YARN)面临的安全威胁

除了上述几大安全部分所具备的缺陷，作为一个开源云计算平台，Hadoop 面临的威胁有：

（1）集中控制模式不够健壮。在 HDFS 中，NameNode 中保存了所有元数据信息。一旦 NameNode 出现故障或者遭受恶意攻击，会使得整个系统不能运行。虽然 Hadoop 中存在一个 SecondNameNode，但它只是保存了 NameNode 中某一时间点的信息和之后的操作日志，在 NameNode 发生故障时不能立即对 NameNode 中的数据进行迅速恢复，不能保证运行的任务不被中断。

（2）基于 ACL 的访问控制机制过于简单。Hadoop 中采用简单的访问控制机制，对访问权限的设定与 Linux—样，存在可读、可写、可执行三个权限，但此简单的访问控制机制显然不能对数据进行很好的保护。

（3）过于依赖 Kerberos。在整个 Hadoop 集群中，只存在一个 Kerberos 服务器，这个服务器负责集群中所有节点的访问控制。当 Hadoop 中节点的数量变大时，Kerberos 负担会加重。若在某一时刻很多节点向服务器请求访问 Token，可能会超出服务器的处理能力。此外，这也是 Hadoop 中心控制问题的一个表现，若 Kerberos 服务器出现故障，则整个集群都无法运行。

（4）无法应对恶意的网络攻击。Hadoop 在设计时没有对可能遭受的网络安全问题进行考虑，Hadoop 中没有对应的网络安全防护措施，很容易受到诸如 Ddos 的攻击，因此 Hadoop 对网络安全的防护只能借助第三方的工具。

（5）大数据用户只能寻求第三方工具维护安全

因为比较缺乏安全维护，目前 Hadoop 上诞生了一定数量的企业级安全解决方案，比如 Cloudera Sentry、IBM InforSphere Optim Data Masking、DataStax 企业版、DataGuise for Hadoop、英特尔的安全办 Hadoop、Protegrity 大数据保护器等。这些企业级安全解决方案一定程度上改善了 Hadoop 的安全状况。此外，Apache Ranger，Apache Rhino，Apache Knox，Gateway 等 Apache 支持的安全项目也使 Hadoop 运行的安全环境得到极大改善。

reference：

陈玺, 马修军, 吕欣. Hadoop 生态体系安全框架综述[J]. 信息安全研究, 2016, 2(8):684-698.

缪璐瑶. Hadoop 安全机制研究[D]. 南京邮电大学, 2015.

下面关于 Hadoop 的文章您也可能喜欢，不妨看看：

Ubuntu14.04 下 Hadoop2.4.1 单机 / 伪分布式安装配置教程 http://www.linuxidc.com/Linux/2015-02/113487.htm

CentOS 6.3 下 Hadoop 伪分布式平台搭建 http://www.linuxidc.com/Linux/2016-11/136789.htm

Ubuntu 14.04 LTS 下安装 Hadoop 1.2.1（伪分布模式）http://www.linuxidc.com/Linux/2016-09/135406.htm

Ubuntu 上搭建 Hadoop 环境（单机模式 + 伪分布模式）http://www.linuxidc.com/Linux/2013-01/77681.htm

实战 CentOS 系统部署 Hadoop 集群服务 http://www.linuxidc.com/Linux/2016-11/137246.htm

Hadoop 2.6.0 HA 高可用集群配置详解 http://www.linuxidc.com/Linux/2016-08/134180.htm

Spark 1.5、Hadoop 2.7 集群环境搭建 http://www.linuxidc.com/Linux/2016-09/135067.htm

在 Ubuntu X64 上编译安装 Hadoop http://www.linuxidc.com/Linux/2016-12/138568.htm