Hive系列(一)metastore的认证和授权

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

1 Hive系列目录

  • Metastore认证和验权
  • HiveServer2认证和验权
  • sentry的权限设计
  • HiveServer2接入sentry后的认证和验权
  • Metastore接入sentry后的认证和验权
  • HiveServer2 thrift服务详细分析

2 Metastore

2.1 Metastore服务介绍

metastore主要维护2种数据:

  • 数据库、表、分区等数据,算是DDL操作
  • 权限、角色类的数据,算是DCL操作

metastore通过开启thrift rpc服务,开启对上述2种数据的操作接口,接口即 ThriftHiveMetastore.Iface 内容见下图

第一种数据的操作如下:

Hive系列(一)metastore的认证和授权_第1张图片

第二种数据的操作如下:

Hive系列(一)metastore的认证和授权_第2张图片

metastore对该接口的实现为:HMSHandler,它主要有以下属性:

  • ThreadLocal threadLocalMS

    RawStore主要用于和数据库打交道,存储上述2种相关数据,RawStore和当前线程进行绑定,默认实现是ObjectStore

  • List preListeners

    当上述2种数据将要发生变化的时候,都会首先调用上述MetaStorePreEventListener执行一些预处理操作,如验证一个用户是否有权限来执行该操作

  • List listeners

    当上述第一种数据发生变化后,会调用上述MetaStoreEventListener执行一些处理

2.2 Metastore服务的认证和验权

由上述可以了解到,在metastore的数据发生修改之前可以进行验权操作,hive默认提供了一个AuthorizationPreEventListener实现了上述MetaStorePreEventListener接口执行一些验权操作

Hive系列(一)metastore的认证和授权_第3张图片

从上面可以看到,仅仅对DDL操作进行了验权,并没有对DCL操作进行验权,这也是一个比较奇怪的地方。即如果你能直连到metastore服务,就可以随意的进行授权操作。

接下来我们详细看看这个认证和授权的过程

涉及到2个接口:

  • HiveMetastoreAuthenticationProvider:认证提供者,用于用户的认证,一个HiveMetastoreAuthenticationProvider对象对应一个用户,该对象包含用户的userName和groups信息

  • HiveMetastoreAuthorizationProvider:授权提供者,用于用户的验权

下面分别来详细说明

2.2.1 Metastore服务的认证

上述HiveMetastoreAuthenticationProvider的默认实现是HadoopDefaultMetastoreAuthenticator,通过hadoop中的UserGroupInformation来获取当前用户名和组的信息,如下所示

Hive系列(一)metastore的认证和授权_第4张图片

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种是非安全方式。

2.2.2 Metastore服务的验权

上一部分我们获取到了用户信息,下面就是要验证用户是否有权限执行相关操作,验权接口就是HiveMetastoreAuthorizationProvider,实现类如下:

Hive系列(一)metastore的认证和授权_第5张图片

默认是DefaultHiveMetastoreAuthorizationProvider。

  • DefaultHiveMetastoreAuthorizationProvider:

    根据userName和groups信息从数据库中获取权限信息来验证用户是否有权限

  • StorageBasedAuthorizationProvider:

    判断一个用户是否对数据库、表等是否有权限依据该用户在HDFS上对这些文件是否有对应的权限

3 总结

总结如下:

  • metastore只做了DDL操作的相关认证,并没有做DCL操作的认证,一旦通过hive cli连接metastore,用户就可以随意进行赋权操作

  • 根据用户和用户所属的groups信息来获取权限,大数据系统中用户和groups关系的维护最好是自己统一维护,而不是借助默认的linux机器上用户和groups的关系,不然之后会有很多麻烦的。

画了一个默认情况下简单的示意图如下:

Hive系列(一)metastore的认证和授权_第6张图片

4 结束语

本篇简单介绍了metastore端的认证和授权,下一篇就再介绍下HiveServer2的认证和授权

转载于:https://my.oschina.net/pingpangkuangmo/blog/693973

你可能感兴趣的:(Hive系列(一)metastore的认证和授权)