一篇文章彻底理解 HIVE 常见的三种 AUTHENTICATION 认证机制的配置与使用

大家好，我是明哥！

本片博文，分享下 HIVE 常见的三种 AUTHENTICATION 认证机制，包括其配置与使用。

1 数据安全概述

数据在企业中作为具有战略意义的重要资产，其安全性受到了越来越高的重视，任何形式的误删除，误修改，越权使用，不慎泄露等，都是重大的安全事件。为了保护数据安全，各企业都实施了严格的数据使用规范和准则，也应用了各种数据安全技术，确保数据的安全使用。

在技术层面，安全有个 3A+1E 的概念，3A+1E 涵盖了安全的方方面面，3A 即 Authentication 认证，Authorization 鉴权，和Audit 审计；1 E 即 Encrption 加密：

• 其中 Authentication 解决的是身份认证的问题，通俗的来说就是验明真身，证明用户确实是他声称的身份而不是由由其它身份伪装而来；
• Authorization 解决的是权限验证问题，即执行某个具体操作前，确认该用户确实有执行该操作的权限，而不是越权行事；
• Audit 解决的是审计问题，是在事后定期查看安全相关操作记录，从而进一步调整安全策略的基础；
• Encrption 解决的是加密与解密问题，分为静态数据的加解密与数据传输过程中的加解密。通过加解密，数据即使被截获了也不会造成安全事故。

针对某一个用户的某一次数据操作来看，Authentication是事前的安全措施，Authorization 是事中的安全措施，Audit是事后的安全措施。三者联动，才能确保真正的安全。这三者之中，Authentication是基础，因为如果不能证明用户身份，一切都无从谈起；而Authorization 是核心和主题，也是具体业务系统实现时大家更关注的地方。

2 HIVE 的 AUTHENTICATION 认证机制概述

具体到大数据组件 Hive，其支持的客户端的 authentication 认证机制，需要通过服务端参数 hive.server2.authentication 来配置，可配置的值有多种，见下图官网截图：

image

在实际应用中，大家经常使用的有以下三种：

• NONE：即不做身份校验；
• LDAP: 使用基于 LDAP/AD 的用户身份校验；
• KERBEROS: 使用 Kerberos/GSSAPI 做身份校验；

客户端，不管是 beeline 等专用 cli 客户端，还是 dbeaver 等通用 jdbc gui 客户端，抑或 JAVA 应用（基于jdbc），都需要根据服务端配置的认证方式，使用对应的方式，进行认证后才能成功连上 hiveserver2，进而提交查询命令。

3 HIVE 常见的三种 AUTHENTICATION 认证机制的应用场景和配置方式

3.1 hive.server2.authentication = none

• 当不需要对用户身份进行校验，可以配置 hive.server2.authentication = none, 这种境况经常用在测试环境，生产环境一般不推荐;
• 此时用户通过各种客户端如 cli/gui/java 登录时，可以不配置用户名和密码, 在服务端 Hive 会认为登录的是匿名用户 anonymous,如：如：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default
• 此时用户通过各种客户端如 cli/gui/java 登录时，也可以配置为任意用户名和任意密码,在服务端 Hive 会认为登录的是用户声明的任意用户（用户名可以是任意用户名，甚至是不存在的用户名；密码可以是任意密码，或不配置密码），如：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n xyz；beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n xyz -p xxxx
• 可以通过 hiveserver2 webui，验证登录的用户身份；

image

3.2 hive.server2.authentication = ldap

• 中大型企业中一般都会有用户身份的统一认证平台，其底层一般都使用 ldap 协议，其具体实现有微软的 ActiveDirectory， 也有 openLdap, ApacheDS等开源实现；
• Hive 提供了基于 Ldap 的认证机制，可以使用企业的统一认证平台，来验证登录hive的用户的身份,其配置方式：hive.server2.authentication = ldap;
• 具体的 ldap 工具的 url，需要通过参数指定：hive.server2.authentication.ldap.url；
• 除了集成商业版的 ActiveDirectory，大数据集群中也可以使用独立安装的开源的ldap工具，此类工具常见的有 openLdap 和 ApacheDS，其中前者在大部分linux发行版中都自带了package安装包，更容易安装，不过主要通过命令行cli进行管理；而后者则自带了gui客户端 Apache Directory Studio，功能更为丰富；以 openLdap为例，其安装命令如下：sudo yum -y install openldap-clients; sudo yum -y install openldap;
• 客户端登录 ldap 认证的 hiveserver2 时，需要提供用户名和密码，hiveserver2 会到ldap中验证用户名和密码，只有验证通过后才能正常登录；
• 以 beeline 登录为例，其命令格式如下：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n hs_cic -p xyzabc;

3.3 hive.server2.authentication = kerberos

• 大数据生态中，大部分组件都支持 kerberos 安全认证；
• 在开启了 kerberos 安全认证的大数据集群环境中，需要交互的各个用户/客户端/服务端，都需要经过 kdc 的认证获得了 ticket 凭证后，才能与其他组件进行正常交互，所以在大数据集群环境中，一旦基础服务 hdfs/yarn/zookeeper 等开启了 kerberos 安全认证，需要与 hdfs/yarn/zk 这些基础组件交互的各个上层组件，如 hive/hbase/spark/flink 等，都需要配置使用相应的 kerberos principal，只有在经过 kdc 验证获得 ticket 后，才能与 hdfs/yarn/zk 进行交互；
• 具体到 hiveserver2，其在跟开启了 kerberos 安全认证的 hdfs/yarn/hbase 等交互时，同样需要配置使用相应的 kerberos principal(一般配置为hive)，且只有在经过 kdc 验证获得 ticket 后，才能与 hdfs/yarn/zk 进行交互,hive-site.xml中，相关配置项截图如下：
• hiveserver2 本身，也可以配置使用 kerberos 认证机制，即要求 hiveserver2 的各种客户端如 cli/gui/java jdbc，只有在通过 kerberos 认证获得ticket 后，才能正常登陆 hiveserver2 进而提交 sql,其配置方式是：hive.server2.authentication = kerberos；

4 开启了 kerberos 安全认证的大数据集群环境中，HIVE 的 kerberos/ldap 认证方式的配置方式和使用细节

• 在开启了 kerberos 安全认证的大数据集群环境中，HIVE既可以配置使用 kerberos 认证机制，也可以配置使用 LDAP 认证机制；
• 其配置方式比较简单，配置参数 hive.server2.authentication = kerberos/ldap 即可；
• 不过在使用方式上，有不少容易犯错的细节，需要强调下。

4.1 kerberos 环境下，hive 的 kerberos 认证方式: hive.server2.authentication = kerberos

• 由于是在kerberos环境下，所以客户端在登录前，需要首先从 kdc 获取 ticket 并维护在 ticket cache中：a valid Kerberos ticket in the ticket cache before connecting：

• 如果是cli等客户端，一般会通过命令 kinit principal_name -kt key_tab_location，基于 keytab 文件来获取特定业务用户的 ticket，并存储在客户端的 ticket cache中；（如果缓存的 ticket 过期了，需要通过命令重新获取；如果不使用keytab, 也可以通过密码来获取 ticket: kinit principal_name）；
• 如果是程序代码，则一般通过 org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(String user, String path) 的方式，基于keytab文件来获取特定业务用户的 ticket，并存储在客户端的 ticket cache中；（UserGroupInformation 在后台会自动基于keytab 文件来定时刷新ticket，确保不会过期）；

• 客户端在获取业务用户的 ticket 成功后，才可以通过 jdbc连接，登录到指定的 hiveserver2：

• 此时需要特别注意下 hiveserver2 的url的格式，其格式推荐使用：jdbc:hive2://xx.xx.xx.xx:10000/default;principal=hive/_HOST@CDH.COM：
• 这里的principal部分，推荐使用三段式来指定，包含pincipal, host 和 realm;
• pincipal 必须指定为系统用户hive，而不能是业务用户如 dap,xyz等（本质上是因为，hive-site.xml 中配置的hive系统用户是hive）；
• host部分，推荐指定为_HOST，此时在底层使用时会替换为 hiveserver2 节点的hostname （当然也可以直接指定为 hiveserver2 节点的具体的 hostname）；
• realm 部分，需要根据实际配置情况进行指定（可以查看配置文件 /etc/krb5.conf）；

4.2 kerberos环境下，hive 的 LDAP 认证方式 : hive.server2.authentication = ldap

• 由于是在kerberos环境下，所以客户端在登录前，需要首先从 kdc 获取 ticket 并维护在 ticket cache中，这一点跟 kerberos 环境下，hive 的 kerberos 认证方式时一直的：a valid Kerberos ticket in the ticket cache before connecting：

• 如果是cli等客户端，一般会通过命令 kinit principal_name -kt key_tab_location，基于 keytab 文件来获取特定业务用户的 ticket，并存储在客户端的 ticket cache中；（如果缓存的 ticket 过期了，需要通过命令重新获取；如果不使用keytab, 也可以通过密码来获取 ticket: kinit principal_name）；
• 如果是程序代码，则一般通过 org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(String user, String path) 的方式，基于keytab文件来获取特定业务用户的 ticket，并存储在客户端的 ticket cache中；（UserGroupInformation 在后台会自动基于keytab 文件来定时刷新ticket，确保不会过期）；

• 客户端在获取业务用户的 ticket 成功后，才可以通过 jdbc连接，登录到指定的 hiveserver2，此时登录格式，跟非 kerberos 环境下，hive 的 ldap认证方式，是一样的：

• 客户端登录 ldap 认证的 hiveserver2 时，需要提供用户名和密码，hiveserver2 会到ldap中验证用户名和密码，只有验证通过后才能正常登录；
• 以 beeline 登录为例，其命令格式如下：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n hs_cic -p xyzabc;

5 大数据平台 CDH/TDH/CDP 与 TDH 中， hive 认证方式的差异

• CDH/TDH/CDP中，在 CDH 5.7 及以后的版本中，Cloudera 对hive的安全认证进行了增强：在大数据集群开启了 kerberos 安全认证的环境下，即使 hive 服务端配置了使用ldap （hive.server2.authentication = ldap），客户端也可以通过url指定使用 KERBEROS 认证方式来登录；
• TDH 中，通过安全组件 Guardian 来管理各个组件的安全，Guardian 底层整合了 kerberos 和 ApacheDS，其推荐的hive认证方式，其实等同于 “kerberos环境下，hive 的 LDAP 认证方式 : hive.server2.authentication = ldap”；
• 在TDH环境下，在大数据集群开启了 kerberos 安全认证的环境下，如果 hive 服务端配置了使用ldap （hive.server2.authentication = ldap），则必须通过kerberos和ldap的双重认证后，才能登陆 hiveserver2；

image

image

6 知识总结

• 数据安全在技术层面，有个 3A+1E 的概念：3A 即 Authentication 认证，Authorization 鉴权，和Audit 审计，1 E 即 Encrption 加密；
• 大数据组件 Hive，其支持的客户端的 authentication 认证机制，需要通过服务端参数 hive.server2.authentication 来配置，可配置的值有多种，常见的有 NONE/LDAP/KERBEROS；
• Hive 的 Ldap 认证机制，可以使用企业的统一认证平台，来验证登录 hive 的用户的身份；
• 在大数据集群开启了 kerberos 安全认证的环境下，hive 支持两种认证方式：kerberos 和 ldap；
• 在大数据集群开启了 kerberos 安全认证的环境下，需要交互的各个用户/客户端/服务端，都需要经过 kdc 的认证获得了 ticket 凭证后，才能与其他组件进行正常交互，所以在大数据集群环境中，一旦基础服务 hdfs/yarn/zookeeper 等开启了 kerberos 安全认证，需要与 hdfs/yarn/zk 这些基础组件交互的各个上层组件，如 hive/hbase/spark/flink 等，都需要配置使用相应的 kerberos principal，只有在经过 kdc 验证获得 ticket 后，才能与 hdfs/yarn/zk 进行交互；
• hiveserver2 在跟开启了 kerberos 安全认证的 hdfs/yarn/hbase 等交互时，同样需要配置使用相应的 kerberos principal(一般配置为hive)，且只有在经过 kdc 验证获得 ticket 后，才能与 hdfs/yarn/zk 进行交互；
• hiveserver2 本身，也可以配置使用 kerberos 认证机制，即要求 hiveserver2 的各种客户端如 cli/gui/java jdbc，只有在通过 kerberos 认证获得ticket 后，才能正常登陆 hiveserver2 进而提交 sql；
• 在大数据集群开启了 kerberos 安全认证的环境下，hive 客户端在登录前，需要首先从 kdc 获取业务用户的 ticket 并维护在 ticket cache中, hive 客户端只有在获取业务用户的 ticket 成功后，才可以通过 jdbc连接，登录到指定的 hiveserver2；
• hiveserver2 在 kerberos 认证方式下，需要特别注意下 hiveserver2 的url的格式，其格式推荐使用：jdbc:hive2://xx.xx.xx.xx:10000/default;principal=hive/_HOST@CDH.COM：
• CDH/TDH/CDP中，在 CDH 5.7 及以后的版本中，Cloudera 对hive的安全认证进行了增强：在大数据集群开启了 kerberos 安全认证的环境下，即使 hive 服务端配置了使用ldap （hive.server2.authentication = ldap），客户端也可以通过url指定使用 KERBEROS 认证方式来登录；
• TDH 中，通过安全组件 Guardian 来管理各个组件的安全，Guardian 底层整合了 kerberos 和 ApacheDS，其推荐的hive认证方式，其实等同于 “kerberos环境下，hive 的 LDAP 认证方式 : hive.server2.authentication = ldap”；
• 在TDH环境下，在大数据集群开启了 kerberos 安全认证的环境下，如果 hive 服务端配置了使用ldap （hive.server2.authentication = ldap），则必须通过kerberos和ldap的双重认证后，才能登陆 hiveserver2；
• hive-site.xml中，相关参数有：

• hive.server2.authentication
• hive.server2.authentication.kerberos.keytab
• hive.server2.authentication.kerberos.principal
• hive.server2.authentication.spnego.keytab
• hive.server2.authentication.spnego.principal
• hive.server2.authentication.ldap.url
• hive.server2.authentication.ldap.baseDN
• hive.server2.authentication.ldap.Domain
• hive.server2.enable.doAs
• hive.metastore.kerberos.keytab.file
• hive.metastore.kerberos.principal