前言
数字化转型大背景下，数据作为企业重要的战略资产，其安全的重要性不言而喻。
我们会通过系列文章，来看下大数据生态中安全框架的实现原理与最佳实践，系列文章一共两篇，包含以下章节：
- 大数据生态安全框架概述
- HDFS 认证详解
- HDFS 授权详解
- HIVE 认证详解
- HIVE 授权详解
- 金融行业大数据安全最佳实践
本片文章是下篇，包含上述后三个章节，希望大家喜欢。
1. HIVE 认证详解
- HIVE 的认证方式，通过参数 hive.server2.authentication 在服务端进行统一配置；
- 该参数可选的值主要有三种：hive.server2.authentication=none/kerberos/ldap
- HIVE的客户端，不管是 beeline 等专用 cli 客户端，还是 dbeaver 等通用 jdbc gui 客户端，抑或 JAVA 应用（基于jdbc），都需要根据服务端配置的认证方式，使用对应的方式，进行认证后才能成功连上 hiveserver2，进而提交查询命令。
- 视乎大数据集群中是否开启了 kerberos，实际的认证方式，分为以下四种：
- 无认证模式
- 只开启LDAP认证模式
- 只开启Kerberos认证模式
- 开启Kerberos和LDAP双重认证模式
1.1 无认证模式:hive.server2.authentication = none
- 当不需要对用户身份进行校验，可以配置 hive.server2.authentication = none, 这种境况经常用在测试环境，生产环境一般不推荐;
- 此时用户通过各种客户端如 cli/gui/java 登录时，可以不配置用户名和密码, 在服务端 Hive 会认为登录的是匿名用户 anonymous,（这点不同于 hdfs, 当没有开启kerberos安全时，如果没有配置 环境变量或系统参数 Hadoop_user_name,hdfs 的默认用户是提交作业的LINUX系统用户）如：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，验证登录的用户身份；
1.2 只开启LDAP认证模式: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 ldapUserName -p ldapUserPwd;
1.3 HIVE 在 kerberos 环境下的认证
- 大数据生态中的各种存储系统，如HDFS/hive/hbase/zookeeper/kafka等，都支持开启Kerberos安全认证；
- 当大数据集群中的存储系统如HDFS/hive/hbase/zookeeper/kafka等开启了kerberos安全认证后，访问这些存储系统的客户端，包含各种计算引擎如 hive/hbase/spark/flink 的系统服务，和用户编写的各种应用如 spark/hive/flink等，都需要经过 kerberos kdc 的认证获得了 ticket 凭证后，才能与这些存储系统进行正常交互；
- 具体到 hiveserver2，其在跟开启了 kerberos 安全认证的 hdfs/yarn/hbase 等交互时，同样需要配置使用相应的 kerberos principal(一般配置为hive)，且只有在经过 kdc 验证获得 ticket 后，才能与 hdfs/yarn/zk 进行交互,hive-site.xml中，相关配置项截图如下：
- 在开启了 kerberos 安全认证的大数据集群环境中，HIVE既可以配置使用 kerberos 认证机制，也可以配置使用 LDAP 认证机制：hive.server2.authentication = kerberos/ldap，分别对应上文所说的，只开启Keberos认证模式 和 开启Kerberos认证和LDA认证模式
1.4 只开启Kerberos认证模式:hive.server2.authentication = kerberos
- 配置hive.server2.authentication = kerberos，即要求 hiveserver2 的各种客户端如 cli/gui/java jdbc，只有在通过 kerberos 认证获得ticket 后，才能正常登陆 hiveserver2 进而提交 sql；
- 由于是在kerberos环境下，所以客户端在登录前，需要首先从 kdc 获取 ticket 并维护在 ticket cache中： a valid Kerberos ticket in the ticket cache before connecting；
- 如果是 cli/beeline 等客户端，一般会通过命令 kinit，基于手工输入的密码或keytab 文件，来获取特定业务用户的 ticket，并存储在客户端的 ticket cache中；（如果缓存的 ticket 过期了，需要重新获取）；
- 如果是程序代码，则一般通过 org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(String user, String path) 的方式，基于keytab文件来获取特定业务用户的 ticket，并存储在客户端的 ticket cache中；（UserGroupInformation 在后台会自动基于keytab 文件来定时刷新ticket，确保不会过期）；
- 客户端在获取业务用户的 ticket 成功后，才可以通过 jdbc连接，登录到指定的 hiveserver2；
- 客户端在获取业务用户的 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）；
1.5 开启Kerberos和LDAP双重认证模式:hive.server2.authentication = ldap
- 配置hive.server2.authentication = ldap，即要求 hiveserver2 的各种客户端如 cli/gui/java jdbc，需要提供用户名和密码，且hiveserver2 会到ldap中验证用户名和密码，只有验证通过后，才能正常登陆 hiveserver2 进而提交 sql；（当然因为整个大数据环境开启了 kerberos, 所以在登录hiveserver2之前，一样要经过 kerberos kdc 的认证）
- 由于是在kerberos环境下，所以客户端在登录前，需要首先从 kdc 获取 ticket 并维护在 ticket cache中，这一点跟 kerberos 环境下，hive 的 kerberos 认证方式时一直的：a valid Kerberos ticket in the ticket cache before connecting：
- 如果是 cli/beeline 等客户端，一般会通过命令 kinit，基于手工输入的密码或keytab 文件，来获取特定业务用户的 ticket，并存储在客户端的 ticket cache中；（如果缓存的 ticket 过期了，需要重新获取）；
- 如果是程序代码，则一般通过 org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(String user, String path) 的方式，基于keytab文件来获取特定业务用户的 ticket，并存储在客户端的 ticket cache中；（UserGroupInformation 在后台会自动基于keytab 文件来定时刷新ticket，确保不会过期）；
- 客户端在获取业务用户的 ticket 成功后，才可以通过 jdbc连接，登录到指定的 hiveserver2，此时登录格式，跟非 kerberos 环境下，hive 的 ldap认证方式，是一样的:
- 此时需要提供用户名和密码，hiveserver2 会到ldap服务器中验证用户名和密码，只有验证通过后才能正常登录；
- 以 beeline 登录为例，其命令格式如下：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n ldapUserName -p ldapUserPwd;
1.6 大数据平台 CDH/TDH/CDP 与 TDH 中，hive 认证方式的差异
- 客户端可用的登录方式，本质上取决于服务端的具体配置；
- 在TDH环境下，在大数据集群开启了 kerberos 安全认证的环境下，如果 hive 服务端配置了使用ldap （hive.server2.authentication = ldap），则必须通过kerberos和ldap的双重认证后，才能登陆 hiveserver2；
- 在 CDH/CDP环境下，在 CDH 5.7 及以后的版本中，Cloudera 对hive的安全认证进行了增强：在大数据集群开启了 kerberos 安全认证的环境下，即使 hive 服务端配置了使用ldap （hive.server2.authentication = ldap），客户端也可以通过url指定使用 KERBEROS 认证方式来登录；此时实际的业务用户，是登录前，通过kinit指定的业务用户！！！此时需要注意，url中需要指定principal=HIVE/_HOST@CDH.COM,以示默认的ldap认证方式下，实际使用的是kerberos认证方式！！！
- TDH 中，通过安全组件 Guardian 来管理各个组件的安全，Guardian 底层整合了 kerberos 和 ApacheDS；
- TDH中，同样支持以上四种认证方式，其推荐的hive认证方式，其实等同于 “kerberos环境下，hive 的 LDAP 认证方式 : hive.server2.authentication = ldap”；
- 在TDH 中配置 inceptor 使用 “开启Kerberos认证和LDAP认证模式” ，并不需要额外安装 OpenLdap/ApacheDS/microsoft AD 等 ldap的具体实现，也不需要跟企业内部统一的 LDAP 服务器打通，也不存在泄露企业域账号用户名和密码的风险，因为底层实际使用的是 Guardien 底层自带的一个 ldap实现（本质是ApacheDS），创建用户更改密码等操作都是在 Guardien 中操作的，跟企业域账户是独立的；
1.7 HIVE认证相关参数
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.metastore.kerberos.keytab.file
- hive.metastore.kerberos.principal
- hive.server2.enable.doAs/hive.server2.enable.impersnation
