一 、Apache Ranger 简介

Apache Ranger 是一个 Hadoop 集群数据安全管理的框架，提供集中式的授权管理及日志审计。它可以对 Hadoop 生态的组件如 HDFS、Yarn、Hive、HBase、Kafka、Storm、Presto、Kylin 等进行细粒度的数据访问控制。通过操作 Ranger Admin 控制台，管理员可以轻松地通过配置策略来控制用户或用户组访问数据的权限。

二、Ranger 对 HDFS 鉴权的实现原理

Ranger 的总体架构图如下图所示，主要由 Ranger Admin、Ranger Usersync 及 Ranger-xx-Plugin 三个部分构成，下面分别介绍三个部分的功能。

1、Ranger Admin

核心组件，是一个独立的进程，提供 RESTFUL 接口来对用户及用户组、服务、策略等进行增删改查，并提供 WebUI 界面可以方便用户进行操作管理，下图即 Ranger Admin web 界面，主要包括以下几个模块：

（1）服务管理（service manager）：目前支持的服务有 HDFS、Yarn、Hive、HBase、Kafka、Storm、Knox、Solr、Nifi 等服务；

（2） 服务（service）：通过某一个服务管理如 HDFS，创建一个服务 service，如 hadoopdev，通过这个服务，ranger 控制台和具体环境的 hdfs 相关联；

（3）策略（policy）：有了某个服务后，如 hadoopdev，可以用这个服务创建相关的策略来管理权限；

（4）审计管理（audit）：对所做的操作及权限进行审计，通过界面可以看到操作日志信息；

（5）用户和用户组管理（users and groups）：可以增加删除修改用户或用户组信息以便对这些用户或用户组设置权限。

2、Ranger-xx-plugin

xx 代表 HDFS、Yarn、Hive、HBase、Kafka、Storm 等服务组件，此插件是轻量级的 java 程序，嵌入到各个服务组件的进程中，定期轮询拉取策略及定期记录访问审计日志。

3、Ranger-UserSync

用户及用户组同步组件。该组件是个独立的进程，将 Linux（Unix）、LDAP 及 AD（windows 的用户域）的用户及用户组信息同步到 Ranger 数据库中，进而可以对这些用户及用户组进行授权。

三、HDFS 鉴权实现原理

HDFS 本身提供了对访问控制列表（ACL）的支持，通过 ACL，可以为特定的用户或者用户组提供文件权限控制。ACL 是不同于用户和组的自然组织层次的有用的权限控制方式，可以为特定的用户和组设置不同的权限，而不仅仅是文件的拥有者和文件所属的组。

HDFS 鉴权过程是在身份认证机制(如 Simple、Kerberos、BCID)之后通过查询 ACLs 来对用户或用户组的权限匹配。注：BCID 是一种中国移动云能力中心自主开发的认证机制。

1、开启权限控制

开启 Ranger 对 HDFS 鉴权，需要修改 hdfs-site.xml 的配置项，即：

<property>      <name>dfs.namenode.inode.attributes.provider.class</name>      <value>org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer</value></property>

其中 RangerHdfsAuthorizer 类是 ranger 中的类，该类继承了 INodeAttributeProvider 类。即 Ranger-hdfs-plugin 将 NameNode 的 Inode Attribute 的提供的抽象类 INodeAttributeProvider 修改为自身实现的 RangerHdfsAuthorizer 类，同时实现类中的接口 AccessControlEnforcer 的 checkPermission 方法。通过 checkPermission 匹配用户或用户组的权限。

2、插件工作过程分析

（1）类加载

在 Namenode 启动过程中加载包 ranger-hdfs-plugin-shim 下的 RangerHdfsAuthorizerorizer 类，将 Ranger HDFS 插件的相关类动态加载到虚拟机，并实例化具体实现类 ranger-hdfs-plugin 包下的 RangerHdfsAuthorizerorizer。类加载代码如下图所示：

（2）插件初始化

通过 RangerHdfsPlugin 类进行初始化 hdfs 插件，RangerHdfsPlugin 是 RangerBasePlugin 类的子类，如下图所示，其具体的初始化是由父类的初始化方法来实现的。

该 init()方法主要完成了以下几个功能：

a、调用 cleanup()方法,设置 refresher、serviceName、policyEngine 这三个变量的值为 null。

b、读取配置文件，并设置变量的初始值，同时设置 PangerPolicyEngineOptions 类的成员变量值。

c、调用 createAdminClient()，创建 RangerAdmin 与 RangerPlugin 通信的客户端。这里使用的基于 RESTful 的通信风格，所以创建 RangerAdminClient 类的实例对象。

d、创建 PolicyRefresher 类的对象，调用 startRefresher()开启策略刷新器，

（3）交互方式分析

初始化之后，通过 RangerAdminClient 类的实例对象与 Ranger Admin 进程通信，使用 PolicyRefresher 类的对象，根据轮询间隔时间定期从 Ranger Admin 拉取更新的策略，同时记录审计日志。

3、插件安装过程分析

Ranger 鉴权本质上是通过读取安装 ranger 插件时生成的配置文件以及插件自带的 jar 包，通过实现可扩展接口或代码注入方式来实现逻辑嵌入到各个服务组件，达到权限管理。在安装服务组件插件过程中，当执行./enable-xxx-plugin.sh 时，主要执行了以下三个步骤：

（1）将插件自带的 conf 更新到安装的服务组件 conf 目录下，并修改相应的服务 conf 属性；

（2）将插件自带的 lib 更新到安装的服务组件 lib 目录下；

（3）将 install.properties 生成.xml 文件，更新到安装的服务组件 conf 目录下。

4、鉴权过程分析

通过插件安装，即开启 ranger hdfs 插件；然后重启 namenode 服务，在重启服务过程中，会加载类、初始化相关配置、变量和 RangerAdminClient 类及 PolicyRefresher 类的对象，这时 Ranger 对 hdfs 的权限控制开始工作。

假设用户的请求是要读写一个 hdfs 文件，下图是 Ranger 对此请求的 hdfs 鉴权流程。其中从 HDFS 进入 ranger 中的入口点是 RagnerHdfsAuthorizer 类，通过此类的内部类 RangerAccessControlEnforcer 的 checkPermission()方法判断是用户是否有权限访问，最终调用的是 isAccessAllowed()方法，此方法根据请求的参数，判断 Ranger 中的 policy 是否匹配，若匹配，则允许访问，否则拒绝访问；同时插件会记录此过程的审计日志。

四、HDFS 细粒度权限实践

现有的 HDFS 服务权限模型（AccessType）如下表：

在一些大数据平台的安全性要求较高的场景中，上述支持的 HDFS 组件权限模型粒度较大，不满足“权限明确，最小权限”原则。例如某用户对 HDFS Path 路径（假设是文件）具有 write 写权限，那么这个用户可以对此文件进行重命名、截断、删除等操作，这样用户可能会有误操作的情况；原本可能只授予用户下载此文件的权限，结果权限模糊或权限扩大，导致可能恶意访问数据的问题发生。

为此我们对 HDFS 权限模型进一步细化，定义更加细粒度的权限模型，使其数据访问控制遵循“权限明确，最小权限”原则，这样解决了权限模糊或权限扩大，进而导致恶意访问数据的问题。

1、细粒度权限模型定义

细粒度授权是为用户或用户组赋予大数据平台中访问数据的操作权限。细粒度授权应可以从不同的数据粒度为用户或用户组赋予可执行的操作。根据数据操作权限必须按需分配，遵循最小化的原则，定义的细粒度权限模型如下：

2、细粒度权限实现

（1）模型支持

首先对 ApacheRanger 的 HDFS 组件 ServiceDefinition 数据模型做了扩展，支持定义的细粒度权限模型，具体涉及到 ranger-admin 模块改造。

（2）鉴权支持

这里提供两种方案：

方案一：namenode 侧细化权限。从 namenode 进程角度看，客户端请求到达 namenode 服务端后，需要解析并区分客户端具体请求的操作（delete or move 等），进而把具体的请求操作封装后调用 Ranger HDFS-plugin 中的方法，再检查是否具有权限。

方案二：Ranger HDFS-plugin 侧细化权限。客户端请求到达 namenode 服务端后，请求调用 Ranger HDFS-plugin 中的方法，其中 namenode 的 Inode Attribute 封装了客户端请求的参数，在 HDFS-plugin 侧进行进一步区分，经过和已有权限策略的对比，检测是否有权限。

3、实践和思考

在实际开发过程中我们采用了方案一，即对 namenode 代码进行了改造。在实践过程中，我们有如下两点思考：

（1）是否可以在 HDFS 客户端请求到达 namenode 校验逻辑之前进行预校验，实现 PRC 的限流？

HDFS 客户端经过参数解析后，预先请求调用 ranger-admin 服务进行预校验，通过后再请求 namenode 服务。这样做对于 namenode 服务负载过高的场景，可以减少 namenode 压力，提升 rpc 性能。

（2）是否可以定义可扩展权限模型？

在实际应用场景中，有些用户可能会恶意触发一些“重”操作（如递归删除一些大文件目录）的行为，这种操作会导致 namenode rpc 请求负载升高，所以有必要定义可扩展的权限模型限制这种操作场景。基于 Ranger HDFS 组件定义的细粒度权限模型，例如可以定义如下可扩展权限模型：

这里定义 heavy 包含 delete、rename 两种权限模型。假设有 HDFS 目录  /user/dir1/dir2/dir3，用户 bch 已经通过了自身身份认证，满足的策略条件有:

a）用户 bch 对目录 /user/dir1/dir2/dir3 有 open,delete,rename 三种权限;

b）用户 bch 对目录/user/dir1/dir2/dir3 有 heavy 权限

当只有同时满足策略条件 a、b 时，用户 bch 才能进行“重”操作，从而增加此类操作的安全性。