Hive系列（一）metastore的认证和授权

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

2.1 Metastore服务介绍

metastore主要维护2种数据：

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

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

第一种数据的操作如下：

第二种数据的操作如下：

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

• ThreadLocal threadLocalMS

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

• List preListeners

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

• List listeners

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

2.2 Metastore服务的认证和验权

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

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

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

涉及到2个接口：

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

• HiveMetastoreAuthorizationProvider：授权提供者，用于用户的验权

下面分别来详细说明

2.2.1 Metastore服务的认证

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

2.2.2 Metastore服务的验权

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

默认是DefaultHiveMetastoreAuthorizationProvider。

• DefaultHiveMetastoreAuthorizationProvider：

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

• StorageBasedAuthorizationProvider：

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

总结如下：

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

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

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

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