大数据安全组件有哪些，各自的优缺点分析及相关配置总结

本帖最后由 howtodown 于 2018-8-15 17:54 编辑
问题导读
1.大数据安全有哪些组件？
2.各自优缺点是什么？
3.Ranger该如何实现配置？

关注公众号，获取最新文章及资源

还有更多资源
关注公众号，获取人工智能20套，区块链资源5阶段
http://www.aboutyun.com/forum.php?mod=viewthread&tid=23842

大数据集群的基本是数据以及用于计算的资源，企业将相应的数据和资源开放给对应的用户使用，防止被窃取、破坏等，这些都涉及到大数据安全。基于以上关键点，考虑到美图公司原有的系统较为庞大复杂，在第一阶段内我们采取轻量级的改造方案进行了大数据集群安全的初探索，接下来通过本文与大家交流相关经验。

由于美图的大数据集群安全迫在眉睫，主要需求有以下几个方面：

支持多组件，最好能支持当前公司技术栈的主要组件，HDFS、HBASE、HIVE、YARN、STORM、KAFKA 等；
支持细粒度的权限控制，可以达到 HIVE 列，HDFS 目录，HBASE 列，YARN 队列，STORM 拓扑，KAKFA 的 TOPIC；
开源，社区活跃，按照现有的集群改情况造改动尽可能的小，而且要符合业界的趋势。

选择大数据安全组件
有了集群安全的需求的下一步就是选择合适的大数据安全组件，目前比较常见的安全方案主要有三种：Kerberos(业界比较常用的方案)、Apache Sentry（Cloudera 选用的方案，cdh 版本中集成）和Apache Ranger(Hortonworks 选用的方案，hdp 发行版中集成)。

Kerberos
Kerberos 是一种基于对称密钥的身份认证协议，作为一个独立的第三方的身份认证服务，可以为其它服务提供身份认证功能，且支持 SSO。

*SSO，即 Single Sign On单点登录。客户端身份认证后，可以访问多个服务，如 HBase/HDFS 等。

如图 1 所示，Kerberos 的协议主要分为 3 个阶段：Client 向 KDC 申请 TGT；Client 通过获得的 TGT 向 KDC 申请用于访问 Service 的 Ticket；Client 用返回的 Ticket 访问 Service。

而这些过程使得它的优点显而易见：服务认证过程有效地防止 broker datanode regionserver 等组件冒充加入集群；解决了服务端到服务端的认证的同时也解决了客户端到服务端的认证。

不可避免， Kerberos 也有短板：

为了安全性使用临时 ticket，认证信息会失效，用户多的情况下重新认证比较繁琐；
Kerberos 只能控制你访问或者拒绝访问一个服务，不能控制到很细的粒度，比如 hdfs 的某一个路径，hive 的某一个表，对用户级别上的认证也没有实现(需要配合 LDAP 服务集成)。

Apache Sentry
Apache Sentry 是 Cloudera 公司发布的一款 Hadoop 安全开源组件，它提供了细粒度级、基于角色的授权。

如图 2 所示，Apache Sentry 目前支持 Hive、Impala、HDFS 等主流组件，它的优点如下：

支持细粒度的 HDFS 元数据访问控制，对 Hive 支持列级别的访问控制；
通过基于角色的授权简化了管理，将访问同一数据集的不同权限级别授予多个角色；
提供统一平台，方便管理；
支持集成 Kerberos。

但 Apache Sentry 支持的组件种类较少，无法支持 Hbase、Yarn、Kafka、Storm等常见组件。

Apache Ranger

Apache Ranger 是 Hortonworks 公司发布的 Hadoop 安全组件开源组件，经过调研我们发现它的优点非常多：

提供细粒度级的权限控制；
权限模型基于访问策略；
权限控制插件式，策略管理统一、方便；
支持各式操作的审计日志，提供统一的查询接口和界面；
支持组件丰富，如 HDFS、HBase、Hive、Yarn、Kafka、Storm 等；
支持和 Kerberos 的集成；
提供 Rest 接口，可供二次开发。

如图 3 Apache Ranger 架构图所示，Ranger Admin 可以支持多种组件，如 HDFS、HBase、Hive、Yarn、Kafka、Storm 等，这些组件可以进行符合标准的自定义拓展再加入到系统中，每个组件通过不同的安装节点实现（如 Hdfs 安装在 NameNode 上）。Ranger Admin 也可以通过独立设置的 SDK 与开放平台进行连接，实现对用户、组以及策略的管理。

权限模型

访问权限定义了「用户-资源-权限」这三者间的关系，Apache Ranger 基于策略来抽象它们之间的关系，进而延伸出它的权限模型。

用户

由 User 或 Group 表示，User 代表访问资源的用户，Group 代表用户所属的用户组。

资源

不同的组件对应的业务资源是不一样的，比如

HDFS 的 FilePath
HBase 的 Table、Column-family、Column
Hive 的 Database、Table、Column
Yarn 的 Queue

权限

由(AllowACL, DenyACL)来表达，类似白名单和黑名单机制，AllowACL 描述允许访问的情况，DenyACL 描述拒绝访问的情况。它的权限控制十分细粒度，不同的组件对应的权限是不一样的：HDFS 支持 Read、Write、Execute；HBase 支持 Read、Write、Create、Admin；Hive 支持 Select、Create、Update、Drop、Alter、Index 、Lock、Read、Write；Yarn 支持 submit-app、admin-queue。

权限实现
Apache Ranger 的权限二元组是由允许和拒绝组成，相当于白名单与黑名单。我们会在 Ranger Admin 的项目里配置一些策略，具体到某一个组件会定期通过 REST 接口把所拥有的策略拉取到相应的服务上，根据策略执行访问决策树，并且记录访问审计。

具体的策略执行过程如图 4 所示，假设我们发起一个请求，以 Hive JDBC 的操作进行模拟，到了 HiveServer 2 里的策略，先将拒绝的策略进行匹配（即先访问黑名单），匹配到黑名单之后再匹配黑名单里的黑名单，这是一个负负得正的过程，相当于允许访问。到了允许访问的阶段再去匹配它的白名单，若白名单匹配到拒绝策略也是直接进行「策略下放」的操作。所有都匹配成功之后，就享有「允许访问」的权限。

*如果没有policy能决策访问，一般情况是认为没有权限拒绝访问，然而Ranger还可以选择将决策下放给系统自身的访问控制层

总结以上策略优先级的处理逻辑可得：

黑名单优先级高于白名单
黑名单排除优先级高于黑名单
白名单排除优先级高于白名单

每个权限控制组件会有自身的权限接口，Ranger 将它们实现之后重写一遍之后，经过权限控制进行权限验证，接下来逐个组件介绍它们的实现原理。

HDFS

hdfs-site.xml 会修改如下配置：

[mw_shl_code=xml,true]<property>
   <name>dfs.permissions.enabled</name>
   <value>true</value>
</property>
<property>
   <name>dfs.permissions</name>
   <value>true</value>
</property>
<property>
   <name>dfs.namenode.inode.attributes.provider.class</name>
   <value>org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer</value>
</property>[/mw_shl_code]

所有的 permission 开启之后将 HDFS 的实现类替换成 Ranger 的实现类，这个实现类会在 HDFS 启动的时候加载一些钩子函数，加载后所有权限都会通过实现类进行访问，同时它会拉取一些访问策略的线程，该线程通过 REST 请求拉取 Ranger Admin 上配置的策略，同时在内存和本地目录中备份，这个配置更新过程约 30S。

加载过程如图 5 所示：

HBase

hbase-site.xml 会修改如下配置：

[mw_shl_code=xml,true]<property>
<name>hbase.security.authorization</name>
<value>true</value>
</property>
<property>
<name>hbase.coprocessor.master.classes</name>
<value>org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor</value>
</property>
<property>
<name>hbase.coprocessor.region.classes</name>
<value>org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor</value>
</property>[/mw_shl_code]

加载过程如图 6 所示：
QQ截图20180815173426.png

Hive
hiveserver2-site.xml 会修改如下配置：

Yarn
yarn-site.xml 会修改如下配置：
[mw_shl_code=xml,true]<property>
<name>yarn.acl.enable</name>
<value>true</value>
</property>
<property>
<name>yarn.authorization-provider</name>
<value>org.apache.ranger.authorization.yarn.authorizer.RangerYarnAuthorizer</value>
</property>[/mw_shl_code]

加载过程如图 8 所示：

其他组件（如 Kafka、Storm 等）的原理也如同以上几个例子，通过实现接口类实现。

美图 Ranger 相关实践
基于美图数据技术团队的现状，综合以下几点考虑进行分析比对，我们选择了 Apache Ranger ：
多组件支持，基本覆盖美图现有技术栈的组件；
支持审计日志，方便查找某个用户在某台机器上提交的任务明细，问题排查反馈通过溯源可以快速完成；
拥有独立用户体系，可以去除 Kerberos 用户体系，方便和其他系统集成，同时提供各类接口调用。
考虑到美图数据平台系统较为庞大复杂，不宜进行太大规模的变动迁徙，我们在第一阶段根据自身情况打造了轻量级的改造方案对大数据集群安全进行了初探索，主要分为以下几个部分：

1.由于美图在调用各服务过程中使用 hdfs shell、hbase-shell、hive-jdbc 只能获取到用户信息，在只有组策略时无法生效。因此我们必须要加入 ldap 组件同步用户组信息，这就增加了系统的复杂性，通过改写 Ranger-Admin 代码，在客户端 plugin 获取策略时将组权限赋予用户，实现了组策略功能。
2.同时我们针对 Ranger 的 api 封装了一个自己的 SDK，方便美图数据开放平台集成 Hive、HDFS、HBase 等相关组件的Ranger 服务调用。
3.由于开源社区的 Ranger 工程标准不统一，我们针对性按照美图大数据研发标准进行自己的版本定制和优化，方便线上运维及日常维护。

以上就是我们第一阶段的实践，在接下来的文章中将会与各位交流美图数据技术团队在 Ranger 上进行第二、三阶段的实践技术经验，欢迎持续关注。

原文链接
作者：美图数据技术团队李玉环