Hadoop UserGroupInformation 的那些 login

如果你只是单纯地使用 Hadoop 的 MapReduce, 也许压根就不需要了解还有个 UserGroupInformation.

当你需要在 Yarn 上做些其它工作时，就必须与 UserGroupInformation 打交道。

先了解下 Hadoop Authentication

然后说明下我要做的是，在当前 jvm 进程的用户并非欲提交作业的用户的情况下，成功切换用户身份信息。

第一个尝试就是直接用用户名、密码登录，生成 Subject, 再调用 UserGroupInformation.loginUserFromSubject(), 起初是一直没有成功，怀疑需要本地系统中存在集群的这个用户才行，添加了用户后还是行不通。只能放弃，转而使用 UserGroupInformation.loginUserFromKeytab(), 居然是同样的错误。经过多方排查，问题的根源定位到 Kerberos 的配置不正确， Kerberos 需要一个 krb5.conf 来指定 kdc 服务器、realm 等配置

[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log[libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 240h renew_lifetime = 7d forwardable = true[realms] EXAMPLE.COM = {  kdc = your-kdc-server  admin_server = kerberos.example.com }[domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM

该文件默认位置是 /etc/, 可以通过 

-Djava.security.krb5.conf=/somewhere/krb5.conf

来指定。只要这个配置文件正确了，用户名密码方式和 keytab 方式都能成功登录 UGI, 但是由于前者的实现是对 hadoop 代码的 hack，是应该极力避免的，因而采用后者。

虽然已经避免了在网络中传输密码的问题，却还是有些不足，传递 keytab 文件也是有风险的，因为 keytab 和密码是一样的有效期。

不久发现了 UGI 的另一个功能 Secure Impersonation，可以存在一个代理用户，认证成功后能够伪装成其他用户的身份

UserGroupInformation realUser = UserGroupInformation.loginUserFromKeytabAndReturnUGI(                        proxyUser), proxyKeytab);UserGroupInformation ugi = UserGroupInformation.createProxyUser(toLoginUsername, realUser);

这样的话，就不需要为每个用户传输 keytab 文件了。

最终，还是采用了另一个途径

UserGroupInformation ugi = UserGroupInformation.getUGIFromTicketCache(ticketCache, username);

这个ticketCache 是可以控制有效期的，是最理想的方案了。

这些认证方式依据需求情况来选择合适的就好。