大家好,我是明哥!
本片博文,分享下 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 来配置,可配置的值有多种,见下图官网截图:
在实际应用中,大家经常使用的有以下三种:
- 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,验证登录的用户身份;
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;
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