Hadoop Delegation Tokens详解

it2022-05-07  0

转载自:《Hadoop Delegation Tokens详解》 https://www.jianshu.com/p/617fa722e057

本文是cloudera公司的一篇技术博客,原文地址:Hadoop Delegation Tokens Explained

译文

Hadoop Security在2009年被设计并实现,此后趋于稳定。但是,由于相关文档不足,当出现问题时很难理解并进行debug。Delegation tokens作为一种认证机制,在Hadoop生态系统中被广泛应用。本文在Hadoop的分布式文件系统(HDFS)和密钥管理服务(KMS)基础上介绍Haodop Delegation Tokens,并提供一些基础代码和简单样例。值得注意的是Hadoop生态中有许多其它的服务也是用到了Delegation Tokens,为了简单起见,这里只讨论Delegation Tokens在HDFS和KMS中的应用。

本文假设读者对基本的认证和Kerberos有一定了解,以了解认证流程,以及HDFS架构和HDFS透明加密。对于那些对HDFS透明加密不感兴趣的读者,可以跳过KMS部分内容。之前的一篇关于Hadoop通用的认证和授权的博文可以点击这里

Hadoop Security简单介绍

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

拒绝未授权的操作访问HDFS中的数据。在实现1的基础上,避免太大的性能损耗。

为了实现第一个目标,我们需要保证:

任何一个客户端要访问集群必须要经过认证,以确保它就是自己声称的身份。集群中任何服务器,需要被认证为集群中的一部分。

为了实现这个目标,Kerberos被选作基础的认证服务。其它的机制,如:Delegation Token, Block Access Token, Trust等被加入当做Kerberos的补充。特别是Delegation Token机制被引入,其主要用以实现第二个目标(详情见下一节)。下图简要描述了Kerberos and Delegation Tokens在HDFS中应用。(其它服务类似)

 

Figure 1: Simplified Diagram of HDFS Authentication Mechanisms

在上面的样例中,会涉及到下面几条认证流程:

用户(joe)利用Kerberos来访问NameNode。用户(joe)提交的分布式任务用joe的Delegation Tokens来访问NameNode。这是本文接下来的重点。HDFS中的DataNode通过Kerberos和NameNode进行交互。用户及其提交的任务通过Block Access Tokens来访问DataNodes。

想要了解更多关于Hadoop Security的设计,可以参考设计文档HADOOP-4487和Hadoop Security Architecture Presentation。

什么是Delegation Token?

理论上,虽然可以只使用Kerberos实现认证机制,但这会有一定问题,尤其是应用在像Hadoop这样的分布式系统中。想像一下,对于每个MapReduce任务,如果所有的任务都需要使用TGT (Ticket Granting Ticket)通过Kerberos来进行认证,KDC(Kerberos Key Distribution Center)将很快成为系统瓶颈。

       下图中的红线说明该问题:一个任务中可能涉及到成千个节点之间的通信,从而导致KDC网络拥堵。事实上,如果集群规模较大,这无意间就对KDC执行了一次DDos(distributed denial of service attack)攻击。

Figure 2: Simplified Diagram Showing The Authentication Scaling Problem in Hadoop

因此,Delegation Tokens作为Kerberos的一个补充,实现了一种轻量级的认证机制。

Kerberos是三方认证协议,而Delegation Tokens只涉及到两方。  

Delegation Tokens的认证过程如下:

client通过Kerberos与Server完成认证,并从server获取相应的Delegation Tokens。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端(图2中的HDFS NN和KMS)主要负责:

发布Delegation Tokens,并保存用以验证。响应更新Delegation Tokens请求。当client端执行删除操作或token过期时,移除Token。通过验证client提供的Tokens和server端存储的token是否一致,来对client进行认证。

Hadoop中Delegation Tokens的生成和验证主要依赖于HMAC机制。Delegation Token主要由两部分组成:public部分和private部分,在Server端以<key,value>形式存储在hashmap中,其中public部分作为key,private部分作为value。

public部分信息用于token识别,以identifier对象形式存在。主要组成如下:

Table 1: Token Identifier (public part of a Delegation Token)

 

private部分信息是由AbstractDelegationTokenSecretManager中的DelegationTokenInformation类来表示,主要组成如下:

Table 2: Delegation Token Information (private part of a Delegation Token)

注意Table1中的Master key ID,其存储于server端,并用于生成每个Delegation Token。该ID会定期更新,且一直只存在于server端。Server同样可以配置更新周期(renew-interval,默认24小时),以及Delegation Token的过期时间。过期的Delegation Tokens不能用于认证,且Server端专门有一个后台线程用于将过期token移除。

只有Delegation Token的renewer可以在token过期前进行更新操作。每次更新过后,token的过期时间会延长一个更新周期(renew-interval),直到token达到最大生命周期(默认7天)。Appendix A中的表格中就是这些配置项的名称及默认值。

client端的Delegation tokens

client主要负责:

从server端请求一个新的Delegation Tokens,请求同时可以指定token的更新者(renewer)。更新Delegation Tokens(如果client将自己指定为renewer),亦或请求别的组件更新token(指定的renewer)向server发送取消Delegation Tokens的请求。提供Delegation Tokens供server进行认证。

client端Token主要包含以下信息:

 

Table 3: Delegation Token at Client Side

Delegation Tokens的认证过程将在下一节介绍。

下面是提交job时的日志的一段摘录,在下面的日志中,我们看到了HDFS Delegation Token和KMS Delegation Token。

job submission

Example: Delegation Tokens的生命周期

我们现在已经知道Delegation Token是什么了,下面来探究下其在实际场景中如何使用。下图展示的是一个运行一个典型应用的认证流程,先通过YARN提交作业,然后将任务分发到各个worker节点执行。

 

Figure 3: How Delegation Token is Used for Authentication In A Typical Job

 

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

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

注意:有一个步骤没有在上图中画出,就是RM会跟踪每个Delegation Token的过期时间,并在即将过期时(达到过期时间的90%)更新Delegation Token。此外,RM是对每个Token进行跟踪,而不是按照Token种类。这样即使每个token的更新间隔(renewal intervals)不同,也能正确地被更新。toekn更新者(renewer)是通过Java ServiceLoader机制实现,因此RM不需要知道Token的种类。对于感兴趣的读者可以阅读DelegationTokenRenewer相关代码。

InvalidToken错误

到目前为止,我们已经了解什么是Delegation Tokens以及其如何在运行作业时使用。下面让我们来看几个典型的Delegation Token相关的错误。

Token is expired

有的时候,应用失败是由于AuthenticationException,其中包含是InvalidToken异常。异常信息显示"Token is expired",猜测下这是为什么?

 

Token is expired

Token can not be found in cache

还有的时候,应用失败也是由InvalidToken造成,而其中的异常日志显示"token can’t be found in cache",猜测下这又是为什么?

 

Token can’t be found in cache

解释

上述两个错误都是由一个共同的原因引起的:被用于认证的token过期了,因此无法使用。第一个异常日志中可以明确看到token过期信息,因为token依然存在于server端。因此,当server验证token有效性的时候,会因token过期而验证失败,抛出“token is expired”异常。现在你可以猜测下第二个异常如何发生的?在"server端的Delegation Tokens"这一小节,我们提到server端有一个后台线程用于移除过期的token。因此,当某个过期token被移除后,server端在进行token验证的过程中就无法找到该token,即抛出"token can’t be found"异常。

Figure 4: Life Cycle of Delegation Token

 

需要注意的是,当一个token被明确的撤销后,那么该token立即会被移除。因此,对于被撤销的token,错误日志只可能是"token can’t be found"。为了进一步debug这些errors,获取client和server端日志中的token序列号(样例中的“sequenceNumber=7” or “sequenceNumber=8”)是非常有必要的,你应该可以看到和token相关的事件信息,如:creations,renewals,cancelations等。

长时间运行的应用

至此,你已经基本了解Hadoop Delegation Tokens。但是还有一点未提及。我们知道Delegations Tokens超过其最大生命周期后无法被更新,那么如果一个任务需要运行时间比token的最大生命周期还要长怎么办?坏消息是,Hadoop无法通过现有的配置解决这一问题。但是好消息是,对于spark-submit提交的任务,Spark已经实现一些"神奇"的参数,Spark获取Delegation Tokens,并用它做认证,这和前面章节提到的内容类似。但是,Spark在token将要过期时并不会更新tokens,而是获取一个新的token。这就可以让应用永远地运行下去。这里是相关代码。需要注意的是,这需要为spark应用生成Kerberos keytab文件。

如果我们实现了一个长时间应用,并希望其能明确地处理token呢?这主要涉及两部分内容:(1)到达最大生命周期前更新token(2)token过期后,需要考虑替换当前token。

实现一个Token Renewer

首先需要了解更新token操作都做了什么,最好的方式是学习YARN RM的DelegationTokenRenewer代码。 这个类中关键点如下:

DelegationTokenRenewer用以管理所有的token,并通过其内部的一个线程池来更新token,还有一个线程用来取消token。更新操作发生在过期时间的90%。取消操作有一个延迟(30秒)用以避免竞争。每个token的过期时间被单独管理,并通过调用renew() API来获取,该方法返回一个过期时间。 dttr.expirationDate = UserGroupInformation.getLoginUser().doAs( new PrivilegedExceptionAction<Long>() { @Override public Long run() throws Exception { return dttr.token.renew(dttr.conf); } });

这就是为什么YARN RM在接收到token后立即更新它,就是为了获取该token的过期时间。

token的最大生命周期是从token的identifier中解码得到,调用其 getMaxDate() API。identifier中的其它字段也可以通过这个API得到。 if (token.getKind().equals(HDFS_DELEGATION_KIND)) { try { AbstractDelegationTokenIdentifier identifier = (AbstractDelegationTokenIdentifier) token.decodeIdentifier(); maxDate = identifier.getMaxDate(); } catch (IOException e) { throw new YarnRuntimeException(e); } } 根据2和3可知,server端不需要通过读取配置文件来确定token过期时间和最大生命周期。由于server的配置可能随时变动,client不应该依赖于它。

最大生命周期后如何处理Token

token的更新者直到最大生命周期才会执行更新操作。最大生命周期后,作业就会失败。如果你的作业是一个长耗时作业,你应该考虑利用YARN documentation about long-lived services中描述的机制,或者为token更新者增加一些自定义逻辑,用来在现有tokens即将过期时,重新获取delegation tokens。

Token的其它用处

恭喜!你已经浏览完delegation tokens的概念和细节,不过还有一些相关内容上文没有提及,下面简单介绍下。

Delegation Tokens在其它服务中的应用,如:Apache Oozie, Apache Hive, and Apache Hadoop’s YARN RM,这些服务都是用Delegation Tokens认证机制。Block Access Token:client在访问HDFS上的文件时,首先需要和NameNode通信,获取该文件的Block位置信息。然后直接和DataNode通信访问这些Blocks。访问权限的检查是在NameNode端完成。但是,client直接访问DataNode中的Block数据,这也需要做权限认证。Block Access Tokens就是用来解决这一问题。Block Access Tokens是由NameNode发布给Client,然后由Client发送给DataNode。Block Access Tokens的生命周期很短(默认10小时),并且不能更新。也就意味着如果一个Block Access Token过期,那么client必须重新获取一个新的token。Authentication Token:我们已经介绍很多的内容都是关于Delegation Tokens。Hadoop中还有一种机制称为:Authentication Token,主要目的是实现一种更轻量级、高可扩展的认证方案。类似于client和server端的cookie。Authentication Tokens由server端授权,且无法更新以及仿冒他人。和Delegation Tokens不同的是,server端不需要单独存储Authentication Tokens,

总结

Delegation Tokens在Hadoop生态中发挥着非常重要的作用,你现在应该理解设计Delegation Tokens的初衷、如何使用以及为什么这么使用。这些内容在开发和debug时尤为重要。

附录

附录A Configurations at the server-side

下面是server端Delegation Tokens相关的配置项。更详细的解释请参考Delegation Tokens at the Server-side

Table 4: Configuration Properties and Default Values for HDFS and KMS

附录B:Example Code of Authenticating with Delegation Tokens

在分析下面代码前需要了解UserGroupInformation (UGI) 这个类,UGI是hadoop中用于完成认证相关操作的API,下面样例中的代码,在上文的异常栈日志中也出现过。

UserGroupInformation tokenUGI = UserGroupInformation.createRemoteUser("user_name"); UserGroupInformation kerberosUGI = UserGroupInformation.loginUserFromKeytabAndReturnUGI("principal_in_keytab", "path_to_keytab_file"); Credentials creds = new Credentials(); kerberosUGI.doAs((PrivilegedExceptionAction<Void>) () -> { Configuration conf = new Configuration(); FileSystem fs = FileSystem.get(conf); fs.getFileStatus(filePath); // ← kerberosUGI can authenticate via Kerberos // get delegation tokens, add them to the provided credentials. set renewer to ‘yarn’ Token<?>[] newTokens = fs.addDelegationTokens("yarn", creds); // Add all the credentials to the UGI object tokenUGI.addCredentials(creds); // Alternatively, you can add the tokens to UGI one by one. // This is functionally the same as the above, but you have the option to log each token acquired. for (Token<?> token : newTokens) { tokenUGI.addToken(token); } return null; });

需要注意的是,addDelegationTokens这一RPC调用会涉及Kerberos认证。否则将会抛出IOException,异常信息:"Delegation Token can be issued only with kerberos or web authentication"。现在,我们可以用获取的delegation token访问HDFS了。

tokenUGI.doAs((PrivilegedExceptionAction<Void>) () -> { Configuration conf = new Configuration(); FileSystem fs = FileSystem.get(conf); fs.getFileStatus(filePath); // ← tokenUGI can authenticate via Delegation Token return null; });

 


最新回复(0)