Kerberos安全工件概述

Cloudera 集群如何使用Kerberos工件，例如principal、keytab和委派令牌。

Cloudera建议使用Kerberos进行身份验证，因为仅原生的Hadoop身份验证仅检查HDFS上下文中的有效成员的user:group身份，而不像Kerberos那样对所有网络资源中的用户或服务进行身份验证。与可能更容易部署的其他机制不同，Kerberos协议仅在特定时间段内对发出请求的用户或服务进行身份验证，并且用户可能要使用的每个服务都需要在协议的上下文中使用适当的Kerberos工件。本节描述Cloudera集群如何使用其中一些工件，例如用于用户身份验证的Kerberos principal和Keytab，以及系统如何使用委派令牌在运行时代表已身份验证的用户对作业进行身份验证。

Kerberos principal

每个需要对Kerberos进行身份验证的用户和服务都需要一个 principal，即一个实体，该实体在可能有多个Kerberos服务器和相关子系统的上下文中唯一标识该用户或服务。principal最多包含三段标识信息，以用户名或服务名（称为“主”）开头 。通常，principal的主要部分由操作系统中的用户帐户名组成，例如 jcarlos用于用户的Unix帐户或 hdfs与主机基础集群节点上的服务守护程序相关联的Linux帐户。

用户的principal通常仅由主要名称和Kerberos领域名称组成。领域是与相同的密钥分发中心（KDC）关联的principal的逻辑分组，该密钥分发中心配置有许多相同的属性，例如受支持的加密算法。大型组织可以使用领域将管理委派给特定用户或功能组的各个组或团队，并在多个服务器之间分配身份验证处理任务。

标准做法是使用组织的域名作为Kerberos领域名称（所有大写字符），以轻松地将其区分为Kerberos principal的一部分，如以下用户principal模式所示：

username@REALM.EXAMPLE.COM

主要名称和领域名称的组合可以将一个用户与另一个用户区分开。例如， jcarlos@SOME-REALM.EXAMPLE.COM并且 jcarlos@ANOTHER-REALM.EXAMPLE.COM可能是同一组织内的唯一个人。

对于服务角色实例标识，主要名称是Hadoop守护程序（hdfs， mapred等）使用的Unix帐户名，后跟一个实例名称，该名称标识运行该服务的特定主机。例如， hdfs/hostname.fqdn.example.com@SOME-REALM.EXAMPLE.COM 是HDFS服务实例的principal的示例。正斜杠（/）使用以下基本模式分隔主要名称和实例名称：

service-name/hostname.fqdn.example.com@REALM.EXAMPLE.COM

Hadoop Web服务接口所需的HTTP principal为其主要节点没有Unix本地帐户，而是 HTTP。

实例名称还可以标识具有特殊角色的用户，例如管理员。例如，principal jcarlos@SOME-REALM.COM和principal jcarlos/admin@SOME-REALM.COM各自具有自己的密码和特权，并且它们可以是或不是同一个人。

例如，在具有每个地理位置领域的组织中的集群上运行的HDFS服务角色实例的principal可能如下：

hdfs/hostname.fqdn.example.com@OAKLAND.EXAMPLE.COM

通常，服务名称是给定服务角色实例使用的Unix帐户名称，例如 hdfs或mapred，如上所示。用于确保对Hadoop服务Web界面进行Web身份验证的HTTP principal没有Unix帐户，因此该principal的principal是 HTTP。

Kerberos Keytab

Keytab是包含principal和用于主要的所述加密密钥的文件。Hadoop守护程序的Keytab文件对于每个主机都是唯一的，因为principal名称包括主机名。该文件用于在主机上向Kerberos认证principal，而无需人工干预或将密码存储在纯文本文件中。由于有权访问principal的keytab文件允许其充当该principal，因此应严格保护对keytab文件的访问。

它们应由最少的一组用户读取，应存储在本地磁盘上，并且不应包含在主机备份中，除非对这些备份的访问与对本地主机的访问一样安全。

委托令牌

Hadoop集群中的用户使用其Kerberos凭据向NameNode进行身份验证。但是，一旦用户通过身份验证，随后还必须检查每个提交的作业，以确保它来自经过身份验证的用户。由于在提交的作业和执行的作业之间可能存在时间间隙，在此期间用户可能已经注销，因此，将使用将来可用于身份验证的委托令牌将用户凭据传递给NameNode。

委托令牌是与NameNode共享的秘密密钥，可用于模拟用户以执行作业。虽然可以更新这些令牌，但是只有客户端使用Kerberos凭据对NameNode进行身份验证时，才能获取新令牌。默认情况下，委托令牌仅在一天内有效。但是，由于作业可以持续一天以上，因此每个令牌都将NodeManager指定为续订者，允许该代理每天续订一次委派令牌，直到作业完成为止，或者最长为7天。作业完成后，NodeManager请求NameNode取消委托令牌。

令牌格式

NameNode使用随机数masterKey生成委托令牌。所有有效令牌均以其到期日期（maxDate）存储在内存中。委托令牌可以在当前时间超过到期日期时过期，也可以被令牌所有者取消。过期或取消的令牌随后从内存中删除。在sequenceNumber 用作用于令牌的唯一ID。以下部分描述了如何使用委托令牌进行身份验证。

TokenID = {ownerID, renewerID, issueDate, maxDate, sequenceNumber}

TokenAuthenticator = HMAC-SHA1(masterKey, TokenID)

Delegation Token = {TokenID, TokenAuthenticator}

认证过程

为了开始身份验证过程，客户端首先将TokenID发送到NameNode。NameNode使用此TokenID和 masterKey再次生成相应的TokenAuthenticator，从而生成委托令牌。如果NameNode发现令牌已经在内存中，并且当前时间小于到期日期（maxDate），则该令牌被视为有效。如果有效，则客户端和NameNode将通过使用它们拥有的TokenAuthenticator作为密钥，并使用MD5作为协议来相互认证。由于客户端和NameNode在此过程中实际上并不交换TokenAuthenticators，因此即使身份验证失败，也不会破坏令牌。

令牌续订

授权令牌必须由指定的续订者（renewerID）定期续订。例如，如果NodeManager是指定的续订者，则NodeManager将首先向NameNode进行身份验证。然后，它将要认证的令牌发送到NameNode。在续订令牌之前，NameNode会验证以下信息：

• 请求续订的NodeManager与令牌中由标识的节点管理器相同的renewerID。

• 由NameNode使用TokenID 和生成的TokenAuthenticator与NameNodemasterKey先前存储的TokenAuthenticator匹配。

• 当前时间必须小于所指定的时间 maxDate。

如果令牌续订请求成功，则NameNode将新的到期日期设置为min(current time+renew period, maxDate)。如果NameNode随时重新启动，它将失去内存中所有先前的令牌。在这种情况下，令牌将再次保存到内存中，这次具有新的到期日期。因此，指定的续订者必须在重启后和重新启动任何失败的任务之前，使用NameNode更新所有令牌。

只要当前时间不超过指定的续订者，也可以恢复已过期或已取消的令牌 maxDate。NameNode无法区分令牌已取消或已过期，以及由于重新启动而从内存中删除的令牌之间的区别，因为只有 masterKey持久性存在于内存中。将 masterKey必须定期更新。

原文链接：https://docs.cloudera.com/cdp-private-cloud-base/7.1.3/security-kerberos-authentication/topics/cm-security-principals-keytabs-overview.html