type
status
date
slug
summary
tags
category
icon
password
Kerberos 存在的问题
以一个例子说明：
Client 将一个计算任务提交到 Yarn 上，分配了 10 个容器，并且分别在 10 个 Worker Nodes 上运行。这 10 个节点为了能够被 Server（比如 NameNode、HiveMetaStore 等）认可，都需要保存一份 keytab（票据），并且都需要跟 KDC（Kerberos 的认证中心）交互。
存在的问题：
1）每个 Worker Nodes 都保存 keytab，大大增加了 keytab 被截获的风险；
2）每个 Worker Nodes 都去访问 KDC，如果节点数和任务数继续增加，KDC性能将成为瓶颈，挂了的话任务都不能继续了。
Delegation Tokens 就是为了解决这个问题出现的。
Delegation Tokens 简介
Kerberos 是三方认证协议，涉及到了 client、KDC、server。
而 Delegation Tokens 只涉及到两方，分别是 client 和 server。
Delegation Tokens 的认证过程如下：
1）client 通过 KDC 与 server 完成认证，并从 server 获取相应的 Delegation Tokens。
2）client 与 server 之间后续的认证都是通过 Delegation Tokens，而不会使用 Keytab。
从这个流程来看，与 KDC 的交互和 keytab 的保存都在 Client 端，然后 Client 把这个 Tokens 上传到 Yarn 后分发到各个 Worker Nodes 上，因此能够避免前述问题。
为了实现这个功能，在 server 端也需要去保存 Delegation Tokens 信息了，以 HiveMetaStore 为例，它提供了在 memory、zookeeper 和 database 三种保存信息的方案。
Delegation Tokens 跟具体的服务绑定在一起，并且也存在一个过期时间。这样，即便信息被坏人截取，也不会有很大的风险。