为什么 Cloudera 要创建 Hadoop 安全组件 Sentry ？

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

1.  大数据的安全体系

要说清楚这个问题，还得从大数据平台安全体系的四个层次说起：外围安全、数据安全、访问安全以及访问行为监控；如下图所示；

外围安全技术多指传统意义上提到的网络安全技术，如防火墙，登陆认证等；

数据安全从狭义上说包括对用户数据的加解密，又可细分为存储加密和传输加密；还包括用户数据的脱敏，脱敏可以看做“轻量级”的数据加密。如某人的生日为“2014-12-12”，脱敏后的数据为“2014-x-x”。数据的轮廓依然存在，但已无法精确定位数值。脱敏的程度越高数据可辨认度越低。上述的例子还可脱敏为“x-x-x”，相当于完全对外屏蔽该信息。

访问安全主要是对用户的授权进行管理。Linux/Unix 系统中用户 - 组的读、写、执行权限管理堪称其中的经典模型。HDFS 对这一概念进行了扩充，形成了更加完备的 ACL 体系；另外随着大数据的应用的普及和深入，文件内部数据访问权限差异化的需求也变得越来越重要；

访问行为监控多指记录用户对系统的访问行为：如查看哪个文件；运行了哪些 SQL 查询；访问行为监控一方面为了进行实时报警，迅速处置非法或者危险的访问行为；另一方面为了事后调查取证，从长期的数据访问行为中分析定位特定的目的。

在这四个安全的层次中，第三层同上层业务的关系最为直接：应用程序的多租户，分权限访问控制都直接依赖这一层的技术实现。

2.  HDFS 的授权体系

在上述的第三层中，Hadoop 生态圈长久以来一直沿用 Linux/Unix 系统的授权管理模型，将文件的访问权限分为读 - 写两种权限（HDFS 上没有可执行文件的概念），将权限的所有者划分为三个大类：拥有者（owner），所在组（group），以及其他人（other）。这种模型限制权限的所有者只能有三类。如果试图增加一个新的“组”，并设定该组的用户拥有不同于 owner，group 或 other 的权限，现有的 Linux/Unix 授权模型是无法优雅地解决这个问题的。

举例来说明上述状况：假设有一个销售部门，部门经理 manager 具有修改销售数据 sales_data 的权利；销售部门的成员具有查看 sales_data 的权利，销售部门以外的人无法看到销售数据 sales_data。那么对于销售数据 sales_data 的授权如下所示：

1. –rw–r—–   3  manager sales      0  2015–01–25  18:51  sales_data 

后来该销售部门扩充了人员，又来两个销售经理，一个叫 manager1，另一个叫 manager2。这两个销售经理也被允许修改销售数据。这种情况下，manager1 和 manager2 只能使用一个新账号 manager_account，然后使该账号能够使用 setuid 对 sales_data 进行修改。这使得对同一份数据的权限管理变得复杂而不容易维护。

由于上述问题的存在，Hadoop2.4.0 中添加了对 HDFS ACL（Access Control Lists）的支持。这一新特性很好地解决了上述的问题。然而随着 Hadoop 在企业中广泛地应用，越来越多的业务场景要求大数据访问控制的粒度也不再局限在文件级别，而是更加细致地约束文件内部的数据哪些能被读写，哪些只能被读，哪些完全不允许被访问。对于基于 SQL 的大数据引擎来说，数据访问不止要到表粒度，更要精确到行列级别。

3.  Hiveserver2 的授权

Hive 是早期将高级查询语言 SQL 引入 Hadoop 平台的引擎之一，早期的 Hive 服务器进程被称作 Hiveserver1；Hiveserver1 既不支持处理并行的多个连接，又不支持访问授权控制；后来这两个问题在 Hiveserver2 上被解决，Hiveserver2 能够使用 grant/revoke 语句来限制用户对数据库、表、视图的访问权限，行列权限的控制是通过生成视图来实现的；但 Hiveserver2 的授权管理体系被认为存在问题，那就是任何通过认证登陆的用户都能够为自己增加对任何资源的访问权限。也就是说 Hiveserver2 提供的不是一种安全的授权体系，Hiveserver2 的授权体系是为防止正常用户误操作而提供保障机制；不是为保护敏感数据的安全性而设计的。然而这些更多的是某些公司的说辞，事实上 Hiveserver2 自身的安全体系也在逐步完善，上述问题也在快速修复中。

但授权管理其实不止是 Hive 需要，其他的查询引擎也迫切需要这些技术来完善和规范应用程序对数据的访问。对于细粒度授权管理的实现，很大一部分功能在各引擎之间是可以公用的，因此独立实现的授权管理工具是非常必要的。

4.  Sentry 提供的安全授权管理

在这样的背景下，Cloudera 公司的一些开发者利用 Hiveserver2 中现有的授权管理模型，扩展并细化了很多细节，完成了一个相对具有使用价值的授权管理工具 Sentry，下图是 Sentry 与 Hiveserver2 中的授权管理模型的对比：

Sentry 的很多基本模型和设计思路都来源于 Hiveserver2，但在其基础之上加强了 RBAC 的概念。在 Sentry 中，所有的权限都只能授予角色，当角色被挂载到用户组的时候，该组内的用户才具有相应的权限。权限à角色à用户组à用户，这一条线的映射关系在 Sentry 中显得尤为清晰，这条线的映射显示了一条权限如何能最后被一个用户所拥有；从权限到角色，再到用户组都是通过 grant/revoke 的 SQL 语句来授予的。从“用户组”到能够影响“用户”是通过 Hadoop 自身的用户 - 组映射来实现的。Hadoop 提供两种映射：一种是本地服务器上的 Linux/Unix 用户到所在组的映射；另一种是通过 LDAP 实现的用户到所属组的映射；后者对于大型系统而言更加适用，因为具有集中配置，易于修改的好处。

Sentry 将 Hiveserver2 中支持的数据对象从数据库 / 表 / 视图扩展到了服务器，URI 以及列粒度。虽然列的权限控制可以用视图来实现，但是对于多用户，表数量巨大的情况，视图的方法会使得给视图命名变得异常复杂；而且用户原先写的针对原表的查询语句，这时就无法直接使用，因为视图的名字可能与原表完全不同。

目前 Sentry1.4 能够支持的授权级别还局限于 SELECT，INSERT，ALL 这三个级别，但后续版本中已经能够支持到与 Hiveserver2 现有的水平。Sentry 来源于 Hiveserver2 中的授权管理模型，但却不局限于只管理 Hive，而希望能管理 Impala, Solr 等其他需要授权管理的查询引擎，Sentry 的架构图如下所示：

Sentry 的体系结构中有三个重要的组件：一是 Binding；二是 Policy Engine；三是 Policy Provider。

Binding 实现了对不同的查询引擎授权，Sentry 将自己的 Hook 函数插入到各 SQL 引擎的编译、执行的不同阶段。这些 Hook 函数起两大作用：一是起过滤器的作用，只放行具有相应数据对象访问权限的 SQL 查询；二是起授权接管的作用，使用了 Sentry 之后，grant/revoke 管理的权限完全被 Sentry 接管，grant/revoke 的执行也完全在 Sentry 中实现；对于所有引擎的授权信息也存储在由 Sentry 设定的统一的数据库中。这样所有引擎的权限就实现了集中管理。

Policy Engine 判定输入的权限要求与已保存的权限描述是否匹配，Policy Provider 负责从文件或者数据库中读取出原先设定的访问权限。Policy Engine 以及 Policy Provider 其实对于任何授权体系来说都是必须的，因此是公共模块，后续还可服务于别的查询引擎。

5.  小结

大数据平台上细粒度的访问权限控制各家都在做，当然平台厂商方面主导的还是 Cloudera 和 Hortonworks 两家，Cloudera 主推 Sentry 为核心的授权体系；Hortonwork 一方面靠对开源社区走向得把控，另一方面靠收购的 XA Secure。无论今后两家公司对大数据平台市场的影响力如何变化，大数据平台上的细粒度授权访问都值得我们去学习。

6.  引用

• http://zh.hortonworks.com/blog/hdfs-acls-fine-grained-permissions-hdfs-files-hadoop/ 
• https://cwiki.apache.org/confluence/display/Hive/SQL+Standard+Based+Hive+Authorization 

更多 Hadoop 相关信息见 Hadoop 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=13

来源：明略数据    原文：http://www.mininglamp.com 作者：明略数据科学家 徐安华