通俗易懂 Kerberos原理

强大的身份验证和建立用户身份是 Hadoop 安全访问的基础。用户需要能够可靠地 “识别” 自己，然后在整个 Hadoop 集群中传播该身份。完成此操作后，这些用户可以访问资源（例如文件或目录）或与集群交互（如运行 MapReduce 作业）。除了用户之外，Hadoop 集群资源本身（例如主机和服务）需要相互进行身份验证，以避免潜在的恶意系统或守护程序 “冒充” 受信任的集群组件来获取数据访问权限。

Hadoop 使用 Kerberos 作为用户和服务的强身份验证和身份传播的基础。Kerberos 是一种计算机网络认证协议，它允许某实体在非安全网络环境下通信，向另一个实体以一种安全的方式证明自己的身份。 Kerberos 是第三方认证机制，其中用户和服务依赖于第三方（Kerberos 服务器）来对彼此进行身份验证。Kerberos服务器本身称为**分发中心或 KDC。在较高的层面上，它有三个部分：

它知道的用户和服务（称为主体）及其各自的 Kerberos 密码的数据库。
一个认证服务器（Authentication Server，简称 AS）：验证Client端的身份（确定你是身份证上的本人），验证通过就会给一张票证授予票证（Ticket Granting Ticket，简称 TGT）给 Client。
一个票据授权服务器（Ticket Granting Server，简称 TGS）：通过 TGT（AS 发送给 Client 的票）获取访问 Server 端的票（Server Ticket，简称 ST）。ST（Service Ticket）也有资料称为 TGS Ticket。

以平时坐火车举例：

通俗易懂 Kerberos原理

一个用户主要来自AS请求认证。AS 返回使用用户主体的 Kerberos密码加密的 TGT ，该密码仅为用户主体和 AS 所知。用户主体使用其 Kerberos 密码在本地解密TGT，从那时起，直到ticket 到期，用户主体可以使用 TGT 从 TGS 获取服务票据。服务票证允许委托人访问服务。

Kerberos 简单来说就是一个用于安全认证第三方协议，它采用了传统的共享**的方式，实现了在网络环境不一定保证安全的环境下，client 和 server 之间的通信，适用于 client/server 模型，由 MIT 开发和实现。
Kerberos 服务是单点登录系统，这意味着您对于每个会话只需向服务进行一次自我验证，即可自动保护该会话过程中所有后续事务的安全。

由于每次解密 TGT 时群集资源（主机或服务）都无法提供密码，因此它们使用称为 keytab 的特殊文件，该文件包含资源主体的身份验证凭据。

Kerberos 服务器控制的主机，用户和服务集称为领域。

二、Kerberos验证过程

Kerberos 验证分为两个阶段：允许进行后续验证的初始验证以及所有后续验证自身。

1、初始验证：票证授予票证

下图显示了如何进行初始验证：

通俗易懂 Kerberos原理

客户端通过从**分发中心(Key Distribution Center, KDC)请求票证授予票证(Ticket-Granting Ticket, TGT)开始 Kerberos 会话。此请求通常在登录时自动完成。

要获取特定服务的其他票证，需要 TGT 。票证授予票证类似于护照。与护照一样，TGT 可标识您的身份并允许您获取多个“签证”，此处的“签证”（票证）不是用于外国，而是用于远程计算机或网络服务。与护照和签证一样，票证授予票证和其他各种票证具有有限的生命周期。区别在于基于 Kerberos 的命令会通知您拥有护照并为您取得签证。您不必亲自执行该事务。

与票证授予票证类似的另一种情况是可以在四个不同的滑雪场使用的三天滑雪入场卷。只要入场券未到期，您就可以在决定要去的任意一个滑雪场出示入场卷，并获取该滑雪场提供的缆车票。获取缆车票后，即可在该滑雪场随意滑雪。如果第二天去另一个滑雪场，您需要再次出示入场卷，并获取新滑雪场的另一张缆车票。区别在于基于 Kerberos 的命令会通知您拥有周末滑雪入场卷，并会为您取得缆车票。因此，您不必亲自执行该事务。
KDC 可创建 TGT ，并采用加密形式将其发送回客户端。客户端使用其口令来解密 TGT 。
拥有有效的 TGT，只要该 TGT 未到期，客户机便可以请求所有类型的网络操作（如 rlogin 或 telnet）的票证。此票证的有效期通常为一天。每次客户端执行唯一的网络操作时，都将从 KDC 请求该操作的票证。

2、后续Kerberos验证

客户机收到初始验证后，每个后续验证都按下图所示的模式进行。

通俗易懂 Kerberos原理

客户机通过向 KDC 发送其 TGT 作为其身份证明，从 KDC 请求特定服务（例如，远程登录到另一台计算机）的票证。
KDC 将该特定服务的票证发送到客户机。

例如，假定用户 joe 要访问已通过要求的 krb5 验证共享的 NFS 文件系统。由于该用户已经通过了验证（即，该用户已经拥有票证授予票证TGT），因此当其尝试访问文件时，NFS 客户机系统将自动透明地从 KDC 获取 NFS 服务的票证。
客户机将票证发送到服务器。

使用 NFS 服务时，NFS 客户机会自动透明地将 NFS 服务的票证发送到 NFS 服务器。
服务器允许此客户机进行访问。

从这些步骤来看，服务器似乎并未与 KDC 通信。但服务器实际上与 KDC 进行了通信，并向 KDC 注册了其自身，正如第一台客户机所执行的操作。为简单起见，该部分已省略。

三、Kerberos基本概念

Key Distribution Center, or KDC

在启用Kerberos的环境中进行身份验证的受信任源。

Kerberos KDC Server

作为**分发中心（KDC）的计算机或服务器。

Kerberos Client

集群中针对KDC进行身份验证的任何计算机。

KDC Admin Account

Ambari用于在KDC中创建主体并生成**表的管理帐户。

credential（凭证）

是一种信息包，其中包含票证和匹配的会话**。凭证使用发出请求的主体的**进行加密。通常，KDC 会生成凭证以响应客户机的票证请求。

realms name

包含 KDC 和许多客户端的 Kerberos 网络，类似于域，俗称为领域。

1、Principal

Kerberos principal（又称为主体）用于在kerberos加密系统中标记一个唯一的身份。主体可以是用户（如joe）或服务（如namenode或hive）。

根据约定，主体名称分为三个部分：主名称、实例和领域。例如，典型的Kerberos主体可以是joe/[email protected]。在本实例中：

joe是主名称。主名称可以是此处所示的用户名或namenode等服务。
admin是实例。对于用户主体，实例是可选的；但对于服务主体，实例则是必需的。例如，如果用户 joe 有时充当系统管理员，则他可以使用 joe/admin 将其自身与平时的用户身份区分开来。同样，如果 joe 在两台不同的主机上拥有帐户，则他可以使用两个具有不同实例的主体名称，例如 joe/node1.example.com 和 joe/node2.example.com。请注意，Kerberos 服务会将 joe 和 joe/admin 视为两个完全不同的主体。

对于服务主体，实例是全限定主机名。例如，node1.example.com就是这种实例。
EXAMPLE.COM是Kerberos领域。领域将在下一小节中介绍。

Hadoop中的每个服务和子服务都必须有自己的主体。给定领域中的 主体名称 由 主名称和实例名称组成，在这种情况下，实例名称是运行该服务的主机的FQDN（Fully Qualified Domain Name）。由于服务未使用密码登录以获取其票证，因此其主体的身份验证凭据存储在keytab**表文件中，该文件从Kerberos数据库中提取并本地存储在服务组件主机上具有服务主体的安全目录中。比如NameNode组件在node1.example.com主机上，启用kerberos之后，会自动生成nn.service.keytab文件，并存储在/etc/security/keytabs目录下，用户所有者是hdfs:hadoop，权限为400，如图所示：

通俗易懂 Kerberos原理

ambari 和 hadoop service 的 principals 都存储 Kerberos KDC 中，如下图所示：

通俗易懂 Kerberos原理

2、Principal和Keytab命名约定

	惯例	示例
Principals	$service_component_nam/[email protected]	nn/[email protected]
Keytabs	$service_component_abbreviation.service.keytab	/etc/security/keytabs/nn.service.keytab

一个 DataNode 的受损 Kerberos 凭据不会自动导致所有 DataNode 的 Kerberos 凭据受损。请注意前面的示例中每个服务主体的主名称。这些主要名称（例如 nn 或 hive ）分别代表 NameNode 或 Hive 服务。每个主要名称都附加了实例名称，即运行它的主机的 FQDN。此约定为在多个主机（如DataNodes和NodeManager）上运行的服务提供唯一的主体名称。添加主机名用于区分，例如，来自 DataNode A 的请求与来自 DataNode B 的请求。这一点很重要，原因如下：

如果多个 DataNode 具有完全相同的主体并同时连接到 NameNode ，并且正在发送的 Kerberos 身份验证器恰好具有相同的时间戳，则身份验证将作为重播请求被拒绝。

3、Ambari Principals

除了 Hadoop 服务主体之外，Ambari 本身还需要一组 Ambari Principal 来执行服务“冒烟”检查，执行警报运行状况检查以及从集群组件检索指标。Ambari Principals 的 Keytab 文件驻留在每个群集主机上，就像服务主体的 keytab 文件一样。

Ambari Principals	描述
Smoke and “Headless” Service users	Ambari 用于执行服务“冒烟”检查并运行警报健康检查。
Ambari Server user	为 Kerberos 启用集群时，组件 REST 端点（例如 YARN ATS 组件）需要 SPNEGO 身份验证。Ambari Server 需要访问这些 API 并需要Kerberos主体才能通过 SPNEGO 针对这些 API 进行身份验证。

4、keytab

keytab 是包含 principals 和加密 principal key 的文件。

keytab 文件对于每个 host 是唯一的，因为 key 中包含 hostname 。keytab 文件用于不需要人工交互和保存纯文本密码，实现到 kerberos 上验证一个主机上的 principal 。

因为服务器上可以访问 keytab 文件即可以以 principal 的身份通过 kerberos 的认证，所以，keytab 文件应该被妥善保存，应该只有少数的用户可以访问。

5、ticket（票证）

ticket 是一种信息包，用于将用户身份安全地传递到服务器或服务。一个票证仅对一台客户机以及某台特定服务器上的一项特殊服务有效。票证包含以下内容：

服务的主体名称
用户的主体名称
用户主机的 IP 地址
时间标记
定义票证生命周期的值
会话**的副本

所有此类数据都使用服务器的服务**进行加密。颁发票证之后，可重用票证直到期为止。

6、 authenticator（验证者）

是服务器用于验证客户机用户主体的信息。验证者包含用户的主体名称、时间标记和其他数据。与票证不同，验证者只能使用一次，通常在请求访问服务时使用。验证者使用客户机和服务器共享的会话**进行加密。通常，客户机会创建验证者，并将其与服务器或服务的票证一同发送，以便向服务器或服务进行验证。

四、票证生命周期

每当主体获取包括票证授予票证 (Ticket–Granting Ticket, TGT) 在内的票证时，可以通过 kinit 的-l 选项指定的生命周期值，前提是使用 kinit 获取票证。缺省情况下，kinit 使用最长生命周期值。kdc.conf 文件中指定的最长生命周期值 (max_life)。

可通过 kinit 的 -r 选项指定的可更新生命周期值，前提是使用 kinit 获取或更新票证。kdc.conf 文件中指定的最长可更新生命周期值 (max_renewable_life)。

五、Kerberos主体名称

每个票证都使用主体名称进行标识。主体名称可以标识用户或服务。以下是一些主体名称的示例：

主体名称	说明
[email protected]	用户的主体
username/[email protected]	admin 主体，可用于管理 KDC 数据库。
K/[email protected]	主名称主体。一个主名称主体可与每个主 KDC 关联。
krbtgt/[email protected]	生成票证授予票证时使用的主体。
kadmin/[email protected]	允许使用 kadmind 访问 KDC 的主 KDC 服务器的主体。
[email protected]	Ambari 用于执行服务“冒烟”检查并运行警报健康检查。
HTTP/[email protected]	用于访问 Hadoop Web UI 时用到的 principal

六、总结

本篇文章主要从 Kerberos 概述、验证过程的描述、基本概念的解释的方面来介绍 Kerberos 的。更多的 Kerberos 相关资料，可参考以下链接，建议都点开看看！

扩展链接

参考资料

https://docs.oracle.com/cd/E19253-01/819-7061/6n91j2vak/index.html（推荐阅读）
https://www.zhihu.com/question/22177404/answer/492680179（推荐阅读）
https://www.anquanke.com/post/id/171552#h2-2（推荐阅读）
https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.4/bk_security/content/kerberos_principals.html
https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.5/bk_security/content/setting_up_kerberos_authentication_for_non_ambari_clusters.html