Hadoop安全基于Kerberos的SASL详解续

工作上由于需要给hive的metastore做逻辑元数据以及支持水平扩展，在waggle-dance的基础上增强了kerberos的功能，上线之后发现运行一天之后，请求失败，报GssException no tgt.

waggle-dance在启动的时候，我调用过了

UserGroupInformation.loginFromKeyTab() 方法， 登录之后，会生成一个全局的loginUser, 后面所有调用UserGroupInformation的地方都会获取到登录过的用户。

登录成功之后，loginUser的subject的privCredcredentials里会有KerberosTicket, 也会有一个KeyTab.

最开始我的疑问是为什么client和跟waggle-dance建立正常的sasl连接，但是waggle-dance却无法跟metastore建立连接呢？

经过服务端debug（可以百度一下，在服务端启动的时候增加一些JVM参数）, 确定了client确实是可以跟waggle-dance建立正常的连接的，报错的日志已经是给waggle-dance跟metastore建立sasl连接失败了。而且发现出现异常的时候，loginUser的subject里的privCredients里的KerberosTicket都不见了。

又增加了一个疑问，这些ticket是什么时候被删除的呢？？

带着这些问题开始找看案，首先是研究了一下类似具有类似代理功能的服务，看看他们是如何做的，于是研究了HiveServer2， RBF。 猜测应该是有一个后台线程定期的更新这些Ticket.

又或者是因为是有了KeyTab了，是不是不需要定期更新Tgt了，底层sasl会自动的获取？

代码翻了一遍没找到，于是寄托与网络，看看能不能找到类似问题，还是没有找到。

解决问题最有效的方式就是debug，首先看看subject里的Tgt都是什么时候加入进去的

在Subject的add方法处增加断点，最后总结出

Kerb5LoginModule在登录成功之后，commit的时候回把KeyTab，TGT放入到subject的privCredcredentials 里面。

在GssKrb5Client 处理evaluateChellenage的地方会初始化 （Krb5Context）GssContext.initSecContext(), 该方法会从subject中获取tgt,并然后获取 service的 serviceTicket, 并把serviceTicket加入到 privCredcredentials里。  

我报错的地方就是在 从subject 获取tgt的时候为空，所以报错是没有合法的tgt.

tgt是什么时候被删除的呢？

在看上一步处理initSecContext的过程中，或获取subject里的tgt,调用Krb5Util.getInitialTicket, 调用SubjectComber.find方法，里面有处理tgt是过期状态，会被删除的逻辑。

后面在看，会不会如果没有tgt，再登录一次呢，这里确实是有这个逻辑的，不过需要参数GSSUtil.useSubjectCredsOnly为true才行，默认都是fasle. 所以不会自动login再获取TGT.

所以，如果tgt如果过期，即使用keytab登录的，如果过期之后，client跟server建立sasl连接的时候，就会失败。

那client为甚们能够跟waggle-dance服务正常的连接呢，接着看了一下GssKrb5Server里的逻辑，同样处理evaluateResponse的时候，会初始化GssContext.acceptSecContext(), 跟客户端GssContext.initSecContect()相对应。 客户端是init, 服务端是accept。 在acceptSecContext里面会生成服务端的serviceTicket, 里面有客户端跟服务端沟通的sessionKey。这里服务端是不需要再跟KDC沟通的，这些都是客户端在evaluateChellengage的时候，把自己获取到的serviceTicket 发送到服务端，服务根据自己的securityKey解码 客户端发送过了的数据，获取到了serviceTicket.接着就可以跟客户交互了。 所以服务端是不需要保存tgt的，只要有keytab就可以了，所以也就没有过期的说法。也就说明了client为啥能正常跟waggle-dance建立连接，是因为client已经拥有了合法的tgt.  waggle-dance server 端有合法的keytab。

搞明白上面这个之后，HiveServer2是如何更新TGT的呢，后来再仔细跟踪了一下代码，HiveServer2使用的是RetryingMetaStoreClient, 在初始化的时候，就会调用

if(ugi.isFromKeytab()) {
   ugi.checkTGTAndReloginFromKeyTab();
}

看了一下注释，如果TGT过期或者临近过期，都会重新生成TGT的。

RBF 也是类似的逻辑，在MountTableRefresherThread 里面，会定期的调用该方法。

到此，所有的疑问都已经解决。

由于Gss的代码是在sun的包下面，是没有开源的，导致debug有些困难，行号对不上。

不过还是那句话，有问题才有进步，在问题中成长。

每次碰到问题，才能更深入的了解一些概念，不然都是以为知己知道，其实还不知道。

由于本人水平有限，难免有不正确的地方，如果发现，欢迎留言指正。