hadoop中的token认证

陈猿解码

发布于 2023-02-28 14:58:42

6820

发布于 2023-02-28 14:58:42

文章被收录于专栏：陈猿解码

周更快变成月更了，但还是要坚持，本文来聊聊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信息，包括如下字段：字段名称字段类型含义 identifierbyte[] 经过序列化的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，再进行后续的处理。