HDFSRPC安全认证Token篇推广

本文主要阐述HDFSRPC安全认证相关的实现。主要介绍Token相关的实现。

写在前面

相关blog

https://blog.csdn.net/hncscwc/article/details/124722784

https://blog.csdn.net/hncscwc/article/details/124958357

Token由来

在探究完Kerberos，我一直在想一个问题，rpcConnection已经完成了验证，那为何还需要token？首先需要对yarn有一定的了解，我们知道mapreduce框架是把目标变成多个map，然后reduce出结果。Yarn在执行多个map、reduce的时候，是通过container来运行的。Container本质上是一个独立程序，执行了yarn分配的任务。当Container进程要去访问hdfs的时候，如果使用Kerberos，kdc验证服务存在的不可靠和性能问题（多机多container并发极高）必然会极大的限制大数据平台的稳定，尤其是当有大量用户请求需要通过kdc来获取tgt票据时。因此Token认证被引入充当kerberos的补充，在兼顾安全认证的同时，性能没有较大的损耗。在hadoop中，token主要包括DelegationToken，以及其他一些token，例如之前文件介绍过的BlockToken，以及yarn中一系列的token。

Token中yarn container流程图

Token的应用

当完成kerberos验证以后，服务主体的可以通过getDelegationToken接口来获取token。当服务主体下面的的进程需要去访问hdfs的时候，可以通过token来访问。

Token的验证也在rpc的sasl中，但是步骤跟简单，如下：

server当收到client negotiate请求以后，会返回多个auth。

auths {
  method: "TOKEN"
  mechanism: "DIGEST-MD5"
  protocol: ""
  serverId: "default"
  challenge: "realm=\"default\",nonce=\"svFDnzmhsk40oN5z6vnUFgYgawR17w+XvxiX1Z3M\",charset=utf-8,algorithm=md5-sess"
}
auths {
  method: "KERBEROS"
  mechanism: "GSSAPI"
  protocol: "root"
  serverId: "node17"
}

client接收完negotiate应答后，可以通过服务主体获取的token来initSaslClient，然后发送Initiate请求。Server接收到Initiate请求，会通过token初始化saslServer，不同于Kerberos，saslserver验证完token会立马complete。这时候server会直接返回success应答给客户端。客户端接收到success应答以后即完成SaslClient的初始化。

可以看出token验证的整个过程更简单，而且本质上就是server验证了一下client的token，消耗更少，性能更高。

token验证本身与用户密码生成没有任何关系，主要都是java原生类来实现。代码如下：

继续阅读https://blog.csdn.net/zfpigpig/article/details/136710003