如何实现Hive库表权限的管理，本文简单介绍了Hive的四种授权模式，并着重介绍了其中基于SQL标准的Hive授权模式场景应用，且与Sentry的区别进行说明。
一、四种授权模式
1.1 基于存储的授权（Storage Based Authorization in the Metastore Server）
Hive作为表存储层。通过HDFS文件/目录权限管理以及Hive元数据配置实现用户访问数据授权。虽然能够保护Metastore中的元数据不被恶意用户破坏，但由于对文件的权限管理，没有提供细粒度（列级别、行级别）的访问控制。Hive 0.12.0版本之后开始支持。
1.2 基于SQL标准的Hive授权（SQL Standards Based Hive Authorization）
基于SQL标准的Hive授权完全兼容SQL的授权模型，不会给现在的用户带来向后兼容的问题，因此被推荐使用。一旦用户迁移到这种更加安全的授权机制后，默认的授权机制可以被遗弃掉。
基于SQL的授权模型可以和基于存储的授权模型（Hive Metastore Server）结合使用。
和Hive的默认授权机制一样，授权确认发生的SQL语句的编译阶段。
为了保证该授权模型起到安全作用，客户端同样需要安全保证，可以通过以下两种方式做到：
（1）用户访问必须且仅可以通过HiveServer2；
（2）限制用户代码和非SQL指令被执行。
授权确认时是以提交SQL指令的用户身份为依据的，但SQL指令是以Hive Server用户身份（即Hive Server的进程用户）被执行的，因此Hive Server用户必须拥有相应目录（文件）的权限（根据SQL指令的不同，所需权限也不同）。
在这种授权模型控制下，拥有权限使用Hive CLI、HDFS commands、Pig command line、'hadoop jar' 等工具（指令）的用户被称为特权用户。在一个组织（团队）内，仅仅一些需要执行ETL相关工作的团队需要这些特殊权限，这些工具的访问不经过HiveServer2，因此它们不受这种授权模型的控制。对于需要通过Hive CLI、Pig和MapReduce访问Hive表的用户，可以通过在Hive Metastore Server中启用Storage Based Authorization来进行相应的权限控制，参考第一种模式；其它情况则可能需要结合Hadoop的安全机制进行。Hive CLI的方式官方建议抛弃，该方式不安全。
大多数的用户（使用SQL语句，并通过ODBC/JDBC访问HiveServer2进行商业分析）是可以使用这种授权模型进行权限控制的。
1.3 通过Apache Ranger & Sentry 授权
Apache Ranger & Sentry 是通过hive提供的插件来做授权，二者可以提供很多先进的特性。
1.4 旧的Hive默认授权（传统模式）
Hive旧的默认授权（2.0.0版本之前）模式有很多遗留的安全隐患。例如，任何用户都可以给自己赋予表或数据库的权限。
该模式和基于SQL标准的授权很相似，它也提供grant/revoke路径控制，但二者的底层机制不同，且互不兼容。该模式仅支持Hive命令行用户，且是一种不安全模式。
二、基于SQL标准的Hive授权场景应用
2.1 场景介绍
1.hive和hdfs用户，具有Hive所有库表的所有权限。
2.团队team1用户组的zhaominhui，具有ODS库student的读数据权限。
2.2 测试环境
CDH版本5.7.4
Hive版本1.1.0
2.3 Hive配置
在CDH中Hive服务配置中的hive-site.xml 的 Hive 服务高级配置代码段（安全阀）配置选项添加如下内容：
<property>
<name>hive.security.authorization.enabled</name>
<value>true</value>
</property>
<property>
<name>hive.users.in.admin.role</name>
<value>hive,hdfs</value>
</property>
<property>
<name>hive.security.authorization.createtable.owner.grants</name>
<value>ALL</value>
</property>
<property>
<name>hive.security.metastore.authorization.manager</name>
<value>org.apache.hadoop.hive.ql.security.authorization.MetaStoreAuthzAPIAuthorizerEmbedOnly,org.apache.hadoop.hive.ql.security.authorization.StorageBasedAuthorizationProvider</value>
</property>
<property>
<name>hive.security.authorization.manager</name>
<value>org.apache.hadoop.hive.ql.security.authorization.plugin.sqlstd.SQLStdConfOnlyAuthorizerFactory</value>
</property>
#下方的配置不添加，会出现Hive授权不可用或不完整的情况。
<property>
<name>hive.security.authorization.task.factory</name>
<value>org.apache.hadoop.hive.ql.parse.authorization.HiveAuthorizationTaskFactoryImpl</value>
</property>
2.4 授权使用
在hadoop及hive所在节点，创建用户zhaominhui，并归属用户组设置为Hive。
[root@hadoop2]# useradd zhaominhui
[root@hadoop2]# passwd zhaominhui
[root@hadoop2 ~]# usermod -a -G hive zhaominhui
设置Hive的家目录归属为hive:hive，权限为771.
#设定 /user/hive/warehouse目录及子目录使用权限设置为771，表示除hive用户之外的用户仅具有读权限。
[hdfs@hadoop1 /opt/cloudera/parcels/CDH-5.7.4-1.cdh5.7.4.p0.2/lib/hive/bin]$ hadoop fs -chmod -R 771 /user/hive/warehouse
#设定/user/hive/warehouse目录及子目录所属用户组及用户为hive
[hdfs@hadoop1 /opt/cloudera/parcels/CDH-5.7.4-1.cdh5.7.4.p0.2/lib/hive/bin]$ hadoop fs -chown -R hive:hive /user/hive/warehouse
使用admin角色，创建角色team1，并赋予该角色读取ODS库student表的权限，将该角色赋予用户zhaominhui.
#以hive身份登录beeline
[root@hadoop1 /opt/cloudera/parcels/CDH-5.7.4-1.cdh5.7.4.p0.2/lib/hive/bin]# ./beeline
beeline> !connect jdbc:hive2://hadoop1:10000
Enter username for jdbc:hive2://hadoop1:10000: hive
Enter password for jdbc:hive2://hadoop1:10000:
0: jdbc:hive2://hadoop1:10000> set role admin;
0: jdbc:hive2://hadoop1:10000> alter databse ods set owner role admin;
#创建角色team1
0: jdbc:hive2://hadoop1:10000> create role team1;
#将表ods.student读取权限赋予team1角色
0: jdbc:hive2://hadoop1:10000> grant select on ods.student to role team1;
#将team1角色权限赋予zhaominhui用户
0: jdbc:hive2://hadoop1:10000> grant team1 to user zhaominhui with admin option;
#查看zhaominhui用户被赋予的角色
0: jdbc:hive2://hadoop1:10000> show role grant user zhaominhui;
+---------+---------------+----------------+----------+--+
| role | grant_option | grant_time | grantor |
+---------+---------------+----------------+----------+--+
| public | false | 0 | |
| team1 | true | 1599186703000 | hive |
+---------+---------------+----------------+----------+--+
#以zhaominhui用户身份登录beeline
[root@hadoop1 /opt/cloudera/parcels/CDH-5.7.4-1.cdh5.7.4.p0.2/lib/hive/bin]# ./beeline
beeline> !connect jdbc:hive2://hadoop1:10000
Enter username for jdbc:hive2://hadoop1:10000: zhaominhui
Enter password for jdbc:hive2://hadoop1:10000:
#查询ods.student表，可以正常读取。
0: jdbc:hive2://hadoop1:10000> select * from ods.student;
+---------------+--+
| student.name |
+---------------+--+
| c |
+---------------+--+
#查询ods.test表，显示无查询权限。
0: jdbc:hive2://hadoop1:10000> select * from ods.test;
Error: Error while compiling statement: FAILED: HiveAccessControlException Permission denied: Principal [name=zhaominhui, type=USER] does not have following privileges for operation QUERY [[SELECT] on Object [type=TABLE_OR_VIEW, name=ods.test]] (state=42000,code=40000)
#插入数据到ods.student表，显示无写入权限。
0: jdbc:hive2://hadoop1:10000> insert into student values("i");
Error: Error while compiling statement: FAILED: HiveAccessControlException Permission denied: Principal [name=zhaominhui, type=USER] does not have following privileges for operation QUERY [[INSERT] on Object [type=TABLE_OR_VIEW, name=ods.student, action=INSERT]] (state=42000,code=40000)
2.5 与Sentry的区别
1）基于SQL标准的Hive授权方式必须保证该用户具有hdfs相关权限方可，而Sentry设置表权限后，自动授予其hdfs数据对应权限；
2）hive和hdfs用户，Sentry方式中必须使用beeline中sql命令授予该用户admin方式才可赋予其ALL权限，而基于SQL标准的Hive授权，在配置文件中设置admin用户后，在beeline客户端不必使用sql命令赋予admin权限，hive/hdfs用户也有Hive所有库表的所有权限。
3）基于SQL标准的Hive授权方式无法对show databases、use databaseName、show tables操作进行权限控制（需要扩展才可实现），而Sentry可以实现show databases、use databaseName、show tables操作的权限控制。
4）基于SQL标准的Hive授权，权限的赋予是以表级别或视图级别进行的，不支持数据库级别的授权。这可能会带来同一个团队成员之间或不同团队成员之间共享数据不方便，均需要以表或视图进行相应的授权，但好处是用户的数据（表或视图）更安全。Sentry支持数据库级别的授权。
三、总结
上述，简述了Hive授权的四种模式，并着重介绍了基于SQL标准的Hive授权模式场景应用实践，并与Sentry进行对比说明。
场景应用实践中，zhaominhui用户是Linux系统用户，将其设置为hive用户组，是为了具有hdfs路径数据的相关权限，否则仅在beeline中设置表权限，而没有hdfs数据的访问等相关权限，是无法实现权限控制的。这里设置的zhaominhui用户所属组为hive，也可以设置为其他用户组，但该用户组必须对hdf路径/user/hive/warehouse/ods.db/student具有读权限，才可实现与上述实践中相同的权限控制效果。需要对该表有读权限的用户都可以归属于该用户组，并可以将team1的角色即具有ods.student表的读取权限赋予用户组，避免多次对用户赋角色。
https://www.cnblogs.com/yurunmiao/p/4441735.html
