hadoop中的token认证

原创
2022/05/12 00:27
阅读数 265

周更快变成月更了,但还是要坚持,本文来聊聊hadoop中的token,涉及到的点如下图所示。




【Hadoop为什么需要Token】


hadoop最初的实现中并没有认证机制,这意味着存储在hadoop中的数据很容易泄露。后来,基于kerberos认证的安全特性被加入到hadoop中,但是基于kerberos的认证在使用过程中,会存在以下问题:

  • 过程比较复杂,认证过程中还需要涉及到第三方的服务

  • kdc服务存在单点问题(不管是可靠性,还是性能瓶颈),尤其是当有大量用户请求需要通过kdc来获取tgt票据时。


因此Token认证被引入充当kerberos的补充,在兼顾安全认证的同时,性能没有较大的损耗。

在hadoop中,token主要包括DelegationToken,以及其他一些token,例如之前文件介绍过的BlockToken,以及yarn中一系列的token。


【Token是什么】


所谓token,本质上就是服务端生成的一串加密字符串,以作为客户端请求的一个“令牌”。  通常而言,用户第一次通过使用账号密码成功登录后,服务端会生成一个token及token的有效时间返回给客户端,此后,客户端只需要在有效时间内带上这个token发送请求即可。而不需要再次带上用户名和密码。


token具有以下优点:

  • 随机性,不可预测性,时效性,无状态,跨域等特点

  • 完全有应用管理,可以避开同源策略

  • 可以避免CSRF攻击

  • 可以在多个服务间共享


【SASL是什么】


token认证通常是在SASL中进行的,接下来就简单介绍下SASL。


简单认证与安全层(Simple Authentication And Security Layer)是一个在网络协议中用来认证和数据加密的框架。它把认证机制从程序中分离开,理论上使用SASL的程序协议都可以使用SASL所支持的全部认证机制(token认证就是其中的一种认证机制)。

认证机制可支持代理认证,这让一个用户可以承担另一个用户的认证。

SASL同样提供数据安全层,这提供了数据完整验证和数据加密,例如DIGEST_MD5提供了数据加密层。


SASL是一种challenge-response的协议,由服务端发送challenge到客户端,客户端基于challenge发送response,这种交互直到服务端被满足并且不再发布新的challenge

challenge和对应的response都是任意长度的二进制数据。其大概流程如下所示:




【Hadoop中的Token认证】


1. Token相关的数据结构

  • SecretManager

    服务端的token管理。每种类型的token,都有一个对应的SecretManager。

    在具体实现中,SecretManager是一个抽象的泛型类,其类型变量是TokenIdentifier。不同类型的Token的管理类均继承该类,实现对应token类型的管理。

    在SecretManager中通常包含了密钥生成的相关信息,同时提供生成密钥,计算生成token密码的相关方法。


  • Token

    也是一个抽象类,用来描述token信息,包括如下字段:


    字段名称
    字段类型
    含义
    identifier byte[]
    经过序列化的identity信息
    password
    byte[]
    经过序列化的密码信息
    kind
    Text
    Token的类型
    service
    Text
    TokenIdentifier的服务类型(一般是实际提供该token认证的服务端的地址)
    renewer
    TokenRenewer
    进行token更新的类


  • TokenIdentifier

    token的标识类,记录了token的类型,以及token用于进行身份验证的相关信息。

    本身也是一个抽象类,不同类型的token直接或间接地继承自该类。


  • Credentials

    提供读写密钥和token信息的类。即提供将密钥与token信息写入IO流或直接写入指定文件,或从IO流或指定文件读取密钥和token信息的接口。


2. Token认证的交互流程

token认证的交互流程,可抽象地分为两个步骤:申请token和token认证。

  • 申请token

    这一步可以是直接显式的通过rpc请求完成,也可以是服务端自动生成。

    例如:用户提交yarn任务时,一般会先将任务所需要的jar包,以及其他资源文件上传到hdfs中,此时客户端与namenode通信后, 会显式地通过rpc请求申请DelegationToken,用于后续任务操作hdfs使用。

    而在ResourceManager处理客户端提交的任务时,会自动生成多个类型的token,并最终传递给ApplicationMaster,用于后续的RPC交互。


  • 使用token进行认证

使用token认证可以逻辑上划分为两个步骤:

1)构造UserGroupInformation(UGI)

在这一步中,主要是通过从文件中读取token信息,并构造credentials,然后保存在ugi实例对象中。



2)完成SASL交互

首先,是否使用SASL,有两个判断条件

  • 是否明确使用kerberos认证

  • ugi实例对象中是否有token

满足上面任意一个条件,都会进行SASL的逻辑,具体流程又包括:

a. 向服务端发送协商请求

在这个SASL协商请求中,主要指明当前SASL的状态为NEGOTIATE,SASL协议的protobuf定义信息如下所示:


message RpcSaslProto {
    enum SaslState {
        SUCCESS = 0;
        NEGOTIATE = 1;
        INITIATE = 2;
        CHALLENGE = 3;
        RESPONSE = 4;
        WRAP = 5;
    }

    message SaslAuth {
        required string method = 1;
        required string mechanism = 2;
        optional string protocol = 3;
        optional string serverId = 4;
        optional bytes challenge = 5;
    }

    optional uint32 version = 1;
    required SaslState state = 2;
    optional bytes token = 3;
    repeated SaslAuth auths = 4;
}


此外,这里还有一个小细节:

在tcp连接建立后,客户端首先会发送一个连接的头信息,包括4字节的字符串"hrpc";1字节的版本号(标识是客户端);1字节的服务类;以及1字节的认证协议(SASL为-33)。服务端会先接收连接头信息,并从中解析出认证协议类型,即是否采用SASL,再进行后续的处理。



b.  服务端发送认证列表

服务端收到协商请求后,将支持的认证方式发送给客户端。对于token认证而言,则是指定token认证类型,以及具体的token类型,并以此构造挑战信息,形成一个SASL响应发送给客户端。需要注意的是,token认证默认会使用DIGEST_MD5对传输数据进行加密。


c. 客户端发送挑战响应

客户端从服务端发送过来的挑战中,拿到对应的token类型,然后从ugi实例对象中找到对应的token信息,并根据token的密钥信息计算出密码信息,然后构造为挑战响应发送给服务端。


d. 服务端挑战响应的处理

服务端收到挑战响应后,从token中解析出密码信息,并保存起来(通常是为客户端构造的ugi实例对象中),供后续的业务处理获取及校验使用。

例如,resourcemanager处理AM的注册请求时,从ugi中获取AMRMToken,再从token中解析出密码(本质上是ApplicationAttempID)。



此后,服务端通知客户端挑战结束,到这里,整个SASL的流程就结束。后面就是进行具体的rpc请求了。


【总结】


小结一下,本文先讲述hadoop中为什么需要token认证,什么是token,token和sasl是什么关系,最后讲解了hadoop中token认证的通用流程。感兴趣的小伙伴可以阅读下相关的源码。下篇文章,将介绍yarn中用到的几个token。


好了,这就是本文的全部内容,如果觉得本文对您有帮助,请点赞在看转发,也欢迎加我微信交流~




本文分享自微信公众号 - hncscwc(gh_383bc7486c1a)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中

作者的其它热门文章

打赏
0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部