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的用户映射源
三种:
- Kerberos;
- LDAP;
- Linux User/Group;官网文档描述的第三种是和hadoop的用户对应;但是真实测试中发现如果是一个hadoop存在但是Linux系统中不存在的用户,无法授权成功;所以这里我认为还是Linux自己的用户和组;
Sentry的授权
是标准的基于角色的授权(Role Base Access Control, RBAC)。
- 资源和权限绑定,权限在Sentry中分为三种:Select,Insert,ALL;
- 权限和角色绑定;
- 角色和用户绑定(用户来自于上面提到的三种);
Sentry权限控制的实现
在Build和Plan之间,添加钩子,来进行权限验证。
参考文档:
https://cwiki.apache.org/confluence/display/SENTRY/Documentation