Delegation Token

Hadoop最初的实现中并没有认证机制，这意味着存储在Hadoop中的数据很容易泄露。在2010年，安全特性被加入Hadoop（HADOOP-4487），主要实现下面两个目标：

1. 拒绝未授权的操作访问HDFS中的数据。
2. 在实现1的基础上，避免太大的性能损耗。
   为了实现第一个目标，我们需要保证：
3. 任何一个客户端要访问集群必须要经过认证，以确保它就是自己声称的身份。
4. 集群中任何服务器，需要被认证为集群中的一部分。其它的机制，如：Delegation Token, Block Access Token, Trust等被加入当做Kerberos的补充。特别是Delegation Token机制被引入。下图简要描述了Kerberos and Delegation Tokens在HDFS中应用
   
   在上面的样例中，会涉及到下面几条认证流程
5. 用户（joe）利用Kerberos来访问NameNode。
6. 用户（joe）提交的分布式任务用joe的Delegation Tokens来访问NameNode。这是本文接下来的重点。
7. HDFS中的DataNode通过Kerberos和NameNode进行交互。
8. 用户及其提交的任务通过Block Access Tokens来访问DataNodes。

为什么要用delegation token

理论上，虽然可以只使用Kerberos实现认证机制，但这会有一定问题，尤其是应用在像Hadoop这样的分布式系统中。想像一下，对于每个MapReduce任务，如果所有的任务都需要使用TGT (Ticket Granting Ticket)通过Kerberos来进行认证，KDC（Kerberos Key Distribution Center）将很快成为系统瓶颈。下图中的红线说明该问题：一个任务中可能涉及到成千个节点之间的通信，从而导致KDC网络拥堵。事实上，如果集群规模较大，这无意间就对KDC执行了一次DDos（distributed denial of service attack）攻击。

因此，Delegation Tokens作为Kerberos的一个补充，实现了一种轻量级的认证机制。Kerberos是三方认证协议，而Delegation Tokens只涉及到两方。
Delegation Tokens的认证过程如下：

1. client通过Kerberos与Server完成认证，并从server获取相应的Delegation Tokens；
2. client与server之间后续的认证都是通过Delegation Tokens，而不进过Kerberos。
   client可以把Delegation Tokens传递给其它的服务（如：YARN），如此一来，这些服务（如：MapReduce任务）以client身份进行认证。换句话说，client可以将身份凭证"委托"给这些服务。Delegation Tokens有一个过期时间的概念，需要周期性的更新以保证其有效性。但是，它也不能无限制的更新，这由最大生命周期控制。此外，在Delegation Token过期前也被取消。
   Delegation Tokens可以避免分发Kerberos TGT 或 keytab，而这些信息一旦泄露，将获得所有服务的访问权限。另一方面，每个Delegation Token与其关联服务严格的绑定在一起，且最终会过期。所以，即使Delegation Token泄露，也不会造成太大损失。此外，Delegation Token使身份凭证的更新更加轻量化。这是因为Token更新过程只涉及到"更新者"和相关服务。token本身并不会改变，所以已经使用token的各个组件并不需要更新。
   考虑到高可用性，Delegation Tokens会被server进行持久化。HDFS NameNode将Delegation Tokens持久化到元数据中（又称为：fsimage and edit logs），KMS会将其以ZNodes形式持久化到ZooKeeper中。即使服务重启或故障切换，Delegation Tokens也会一直可用。
   server和client在处理Delegation Tokens时会有不同的职责

server端的Delegation Tokens
server端主要负责：

1. 发布Delegation Tokens，并保存用以验证。
2. 响应更新Delegation Tokens请求。
3. 当client端执行删除操作或token过期时，移除Token。
4. 通过验证client提供的Tokens和server端存储的token是否一致，来对client进行认证。
   只有Delegation Token的renewer可以在token过期前进行更新操作。每次更新过后，token的过期时间会延长一个更新周期（renew-interval），直到token达到最大生命周期（默认7天）。
   client端的Delegation tokens
   client主要负责：
5. 从server端请求一个新的Delegation Tokens，请求同时可以指定token的更新者（renewer）。
6. 更新Delegation Tokens（如果client将自己指定为renewer），亦或请求别的组件更新token（指定的renewer）
7. 向server发送取消Delegation Tokens的请求。
8. 提供Delegation Tokens供server进行认证。

Delegation Token 生命周期

下面来探究下其在实际场景中如何使用。下图展示的是一个运行一个典型应用的认证流程，先通过YARN提交作业，然后将任务分发到各个worker节点执行。

简单起见，此处将忽略Kerberos认证和Task分发流程。图中通常有5个步骤：

1. client希望在集群中运行一个job，它分别从NameNode和KMS获取HDFS Delegation Token和KMS Delegation Token。
2. client将作业提交到YARN资源管理器（RM），同时提交的还有step1中获取的Delegation Token以及ApplicationSubmissionContext。
3. YARN RM通过更新操作来核实接收的Token，随后，YARN启动job，并将其和Delegation Tokens一同分发到各个worker节点上。
4. 每个工作节点中的Task利用这些Token来进行认证，比如：需要访问HDFS上数据时，使用HDFS Delegation Token进行认证。需要解密HDFS加密区的文件时，使用KMS Delegation Token。
5. job结束后，RM则取消该job的Delegation Tokens。

NameNode中Delegation Token的实现