企业私有云大数据平台权限管理分享（一）

前言

近年来，越来越多的企业享受大数据平台实施带来的数据价值，也期望接入更多的企业数据及开放不同业务域的数据给不同的用户。因此，在大数据平台构建过程中，需实现完整的权限管理流程，给正确的用户以访问正确的资源权限，避免数据被窃取和被破坏。本文基于此背景，介绍大数据平台通用权限管理框架Ranger 的原理、企业级权限管理设计以及一些实践分享。希望能给大家在大数据平台权限管理落地上提供一些参考。

Ranger 原理介绍

众所周知，一些常用的权限管控模型主要有:

ACL(Access Control List): 基于用户级别的权限控制；
RBAC(Role Base Access Control): 基于角色级别的权限控制；与ACL 不同的是RBAC 不用给用户单个分配权限，权限与用户之间通过角色关联；
ABAC(Attribute Base Access Control): 基于属性级别的权限控制；通过动态计算一个或者一组属性是否满足某种条件来进行权限判断，可以实现细粒度且灵活的权限控制。

详细的权限管理模型和流程可以搜索博文权限管理数据模型、权限申请审批与认证流总结;

目前已有的授权管理开源框架有Sentry 和 Ranger。Sentry 是由Cloudera 公司开发，在CDH 集群中提供的权限管理框架；Ranger 最初是由Hortonworks 主导开发，在HDP 集群中集成使用，后续Cloudera 和 Hortonworks 两家公司合并后统一推出的大数据平台产品CDP 中默认提供的是Ranger。两者都可以做到基于RBAC 权限管控模型做到细粒度的Hdadoop 系统权限管理的，而Ranger 对比Sentry 更加通用，支持的资源也更多。Ranger 通过与Atlas 集成还可以做到基于ABAC 的权限管控。

如上流程图所示，Ranger 是集中式的权限管理，可以通过Web UI或REST API 管理，基于策略的访问权限控制，支持多种大数据组件资源，如HDFS、Hive、Kafka、Yarn、Atlas和Nifi等，并提供审计功能，使用户的操作有迹可循。

Ranger 主体包含了三个服务：

Ranger Admin: 提供权限策略管控服务，分配相应资源给对应的用户、组或者角色。
Ranger UserSync: 提供用户和组同步服务，启动时和每一小时同步一次用户，可以同步LDAP/AD、UNIX和文件中定义的用户。
Ranger TagSync: 主要用于和Atlas 集成，同步Atlas 上定义的Tag，可以做基于Tag 的权限控制。

Ranger 支持的外围资源组件Plugin 会默认每隔30s 向RangerAdmin 拉取一次策略，记录缓存和版本号。

总体来讲，Ranger 利用大数据组件自身的鉴权方案，插件化的集成多种资源，具有很好的通用能力，有统一的Web UI提供便捷直观的管理，同时提供丰富的REST API 便于二次开发，可扩展性强。

企业权限管理实施

企业内员工的流入和流出量大，新旧人员的数据权限管理大大增加了企业管理成本，因此企业中往往使用统一的集中式的员工账号体系，管理员工在不同系统中的资源权限，就我们项目上的客户就使用Microsoft Active Directory 统一集团几万名员工的账号管理。企业员工可以使用自己的AD 账号登录支持AD 认证的软件或者组件使用其服务。一些分析型部门会使用AD 账号登录报表工具或者直连支持AD 的数据库进行分析和查看数据。

AD 本身是内建有Kerberos 支持的，而Kerberos 是Hadoop 生态系统中应用最广的集中式统一用户认证管理框架。之前介绍中，Ranger 也很好的支持了AD 的用户和组同步。

对于大数据平台多租户场景，设计以AD Group 为主体的权限控制，在Ranger 中设定好Role 和 AD Group的对应关系与RBAC 管理策略后，只需要在AD 上将成员加入到对应Group 上即可获得相应资源的权限。

这样设计的优势是统一大数据资源组件和其他支持AD 的报表工具或数据库的权限管控，只需管理对应的AD Group，而对于经常需要新增或者调整细粒度权限控制时，需要在AD 管理到Role 与Group映射关系建立整个流程上调整。
简要流程如下：

在AD Server中新建好约定好的Group（约定OU 和 CN）
Ranger 中UserSync 服务同步Group 和User
在Ranger 中配置Role 和Group的对应关系、Role 访问相应资源的Policy
各个资源的Plugin 同步Ranger 中的Policy 以做权限校验

以下是具体链路流程图:

在具体实践前，需要理解AD/LDAP 中的一些LDAP 基础概念;
需要注意Ranger 配置中的User Search Base & Fliter 和 Group Search Base & Fliter 规则（CN 可以使用星号*匹配），两者是相互影响的。具体配置可以参考这篇文章Ranger Usersync

小Tips: 在配置具体Sync 规则前，可以使用LDAP 命令search 验证一下。参考LDAP Query Basic Examples

Ranger 资源管理与审计

Ranger 支持的大数据资源非常丰富且权限项也比较完整，见下表

在Ranger 权限策略访问决策树中支持黑白名单的，具体优先级是黑名单优先级高于白名单，黑名单排除优先级高于黑名单，白名单排除优先级高于白名单，白名单排除优先级高于白名单。
此外，如果没有policy 能决策访问，一般是认为没有权限拒绝访问的，然而Ranger 还可以选择将决策放给系统自身的访问控制层。如HDFS 支持hdfs-acl。

Ranger 可以提供多方面的审计信息，如用户访问资源记录，管理员更新Policy记录，Ranger Web UI登录session记录，资源Plugins同步情况和状态以及用户同步记录。其中最关心的是Access log，如下图所示：

具体的字段含义可以在这里查看Ranger Audit Schema
需要注意的是Ranger 的审计日志量非常大，还会写入到Solr 中，如果Solr 角色配置的内存不足，很容易出现内存溢出的情况，目前项目上的实践是去掉不必要的审计（非业务数据组件不接入审计）、缩短审计日志保存时间和增大Solr 内存。

Two More Things

Security Zone

Ranger 还支持Security Zone 功能，可以将多个资源划分到不同的Security Zone中，并给Security Zone分配不同的管理员进行权限管理。
如：

Zone: finance
 service: prod_hdfs; path=/finance/*, /taxes/*
 service: prod_hive; database=finance
 service: prod_kafka; topic=FIN_*
 service: test_hadoop; path=/finance/*, /taxes/*

Zone: sales
 service: prod_hdfs; path=/sales/*
 service: prod_hive; database=sales
 service: prod_kafka; topic=SALES_*

可以在Ranger 配置中配置Admin User fliter，然后创建Security Zone 配置相应资源和Admin用户，注意配置Zone的资源权限时不要配置属于其他Zone的资源权限，Ranger Plugin鉴权时会先判断资源属于哪个Security Zone，然后只使用该Security Zone中配置的权限进行鉴权，如果未找到所属Zone，则使用未划分Zone 的权限鉴权。

扩展：Data Mesh 的一种实现？

Ranger RMS

Hive 的物理存储路径是HDFS 上，对于多种任务的访问权限支持，往往需要在Ranger 上配置HDFS 文件和目录权限以及Hive的权限。而Ranger RMS 支持自动使用Hive 的策略直接访问对于表的HDFS 数据方法，减少了策略管理的开销。
具体设计和实现可以参考Ranger RMS。注：目前为止，我们暂未在项目上使用该组件。

总结和展望

本文介绍了使用Ranger 进行企业大数据平台资源管理实践及过程中一些注意事项，当然还有一些其他方面的问题，如实时鉴权、Spark SQL 访问Hive 细粒度支持、批量权限管理及策略量大的场景下同步和拉取的问题等；好在Ranger 的设计是插件化且提供了丰富的REST API，许多企业也对Ranger 及其Plugins 进行了二次开发已解决以上一些问题。

而企业大数据平台权限管理就止步于此了吗？显然不是，下一篇将给大家带来基于CDP(Cloudera Private Platform) 上开发、运维链路上权限管理的更多实践，感谢阅读。