这篇文章将为大家详细讲解有关Hive中metastore如何认证和授权,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。
metastore主要维护2种数据:
数据库、表、分区等数据,算是DDL操作
权限、角色类的数据,算是DCL操作
metastore通过开启thrift rpc服务,开启对上述2种数据的操作接口,接口即 ThriftHiveMetastore.Iface 内容见下图
第一种数据的操作如下:
第二种数据的操作如下:
metastore对该接口的实现为:HMSHandler,它主要有以下属性:
ThreadLocal<RawStore> threadLocalMS
RawStore主要用于和数据库打交道,存储上述2种相关数据,RawStore和当前线程进行绑定,默认实现是ObjectStore
List<MetaStorePreEventListener> preListeners
当上述2种数据将要发生变化的时候,都会首先调用上述MetaStorePreEventListener执行一些预处理操作,如验证一个用户是否有权限来执行该操作
List<MetaStoreEventListener> listeners
当上述第一种数据发生变化后,会调用上述MetaStoreEventListener执行一些处理
由上述可以了解到,在metastore的数据发生修改之前可以进行验权操作,hive默认提供了一个AuthorizationPreEventListener实现了上述MetaStorePreEventListener接口执行一些验权操作
从上面可以看到,仅仅对DDL操作进行了验权,并没有对DCL操作进行验权,这也是一个比较奇怪的地方。即如果你能直连到metastore服务,就可以随意的进行授权操作。
接下来我们详细看看这个认证和授权的过程
涉及到2个接口:
HiveMetastoreAuthenticationProvider:认证提供者,用于用户的认证,一个HiveMetastoreAuthenticationProvider对象对应一个用户,该对象包含用户的userName和groups信息
HiveMetastoreAuthorizationProvider:授权提供者,用于用户的验权
下面分别来详细说明
上述HiveMetastoreAuthenticationProvider的默认实现是HadoopDefaultMetastoreAuthenticator,通过hadoop中的UserGroupInformation来获取当前用户名和组的信息,如下所示
metastore的client端用户是如何被传递到这里的呢?
这就涉及到了metastore开启的thrift rpc服务了,metastore使用的是thrift的TThreadPoolServer来作为server。这种模式下,会启动一个线程池,每来一个客户端连接就取出一个线程来专门处理该连接,该连接就一直占用该线程了,这种方式就是传统的BIO方式,能够支持的并发量比较小。
metastore开启的rpc服务分成3种类型:
使用sasl方式: 是一种安全的方式,使用kerberos认证用户的身份,这一部分内容比较多,可能之后再详细分析这一块。
setUgi方式:
是一种非安全的方式,即并没有对用户的身份进行合法性验证。当hive.metastore.execute.setugi=true时即采用这种模式。这种模式下如下操作:
client端会通过set_ugi方法来向服务器端传递用户的ugi信息
服务器端将用户的ugi信息绑定到当前连接上
client端向服务器端发送操作数据的请求,服务器端取出连接中的ugi信息,使用ugi的doas方法来执行操作
client占用服务器端的一个线程,会创建出一个HiveMetastoreAuthenticationProvider对象,该对象在创建过程中要获取当前的ugi信息,即获取到上述ugi信息,并且把client的上述HiveMetastoreAuthenticationProvider对象绑定在该线程中,至此便可以得到client的用户信息。而groups信息则是通过hadoop默认的方式即获取本metastore服务所在的机器上,该用户所属的groups信息。
其他:
就仅仅是将client的ip绑定到当前线程上,就没有所谓的用户信息了
上述的sasl也是通过ugi.doas方式来供后续获取用户信息的,但是sasl多了用户身份合法性的验证过程。而setUgi方式client端传过来什么用户就认为是什么用户,所以只有sasl方式才是安全的方式,其他2种是非安全方式。
上一部分我们获取到了用户信息,下面就是要验证用户是否有权限执行相关操作,验权接口就是HiveMetastoreAuthorizationProvider,实现类如下:
默认是DefaultHiveMetastoreAuthorizationProvider。
DefaultHiveMetastoreAuthorizationProvider:
根据userName和groups信息从数据库中获取权限信息来验证用户是否有权限
StorageBasedAuthorizationProvider:
判断一个用户是否对数据库、表等是否有权限依据该用户在HDFS上对这些文件是否有对应的权限
总结如下:
metastore只做了DDL操作的相关认证,并没有做DCL操作的认证,一旦通过hive cli连接metastore,用户就可以随意进行赋权操作
根据用户和用户所属的groups信息来获取权限,大数据系统中用户和groups关系的维护最好是自己统一维护,而不是借助默认的linux机器上用户和groups的关系,不然之后会有很多麻烦的。
画了一个默认情况下简单的示意图如下:
关于“Hive中metastore如何认证和授权”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,使各位可以学到更多知识,如果觉得文章不错,请把它分享出去让更多的人看到。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。