Sentry深入

Sentry的架构

内部架构

核心就是规则引擎以及Metadata Store；记录格式有两种，一种policy file记录授权内容，另外一种是通过命令方式进行授权；前者记录在策略文件中，保存形式是hdfs的一个文件；后者则是记录在数据库中，保存在关系型数据库中（通常和hive的metadata保存在一个MySQL实例中）。

调用模型

Sentry Server对外公开PRC端口以及Web 服务两种接口（以PRC为主），供外界调用；在通过cloudera安装sentry的时候，其实已经把Sentry Server以及Sentry Client安装好了（测试集群只是有hive，默认hive在安装完了sentry之后即和sentry绑定）；

Sentry Client

Client种类

Sentry的Hadoop ACL Sync

这些客户端中，HDFS的client比较特殊；因为已经在hive中设置了sentry权限，hive本身就是访问hdfs文件，为什么还要在hdfs层再做权限控制呢？这是因为除了hive可以直接访问hdfs的文件之外，还有Map-Reduce程序，pig，spark等可以访问hdfs，所以只是在hive层面去做是不够的；

在cloudera中可以通过配置hdfs的Enable Sentry Synchronization选项来实现hive权限直接下放；比如你在hive中配置了bd这个用户可以访问sentry_test这个表；那么用bd这个用户在命令行中就可以访问/user/hive/warehouse/sentry_test目录；但是不能访问同级的其他目录以及上级目录。

Hdfs在这里的权限控制是在首先是走sentry的权限控制，如果Sentry中没有配置，才是走文件的权限控制。

1.1.1.1

Sentry权限控制

Sentry的用户映射源

三种：

1. Kerberos;
2. LDAP;
3. Linux User/Group；官网文档描述的第三种是和hadoop的用户对应；但是真实测试中发现如果是一个hadoop存在但是Linux系统中不存在的用户，无法授权成功；所以这里我认为还是Linux自己的用户和组；

Sentry的授权

是标准的基于角色的授权（Role Base Access Control， RBAC）。

1. 资源和权限绑定，权限在Sentry中分为三种：Select，Insert，ALL；
2. 权限和角色绑定；
3. 角色和用户绑定（用户来自于上面提到的三种）；

Sentry权限控制的实现

在Build和Plan之间，添加钩子，来进行权限验证。

参考文档：

https://cwiki.apache.org/confluence/display/SENTRY/Documentation

https://cwiki.apache.org/confluence/display/SENTRY/Sentry+Architecture+Overview?preview=/68718662/68718661/Sentry%20Architectures.pdf