系统环境
- 操作系统：CentOS 6 或 CentOS 7
- JDK 版本：1.8.0_151
- Ambari 版本：2.6.1
- HDP 版本：2.6.4.0
扩展链接
- 《Kerberos原理--经典对话》
- 《基于ambari的Kerberos安装配置》
- 《Windows本地安装配置Kerberos客户端》
- 《Kerberos实战》
- 《基于Ambari禁用Kerberos》
一、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。
以平时坐火车举例：
（图片来源于网络）
一个用户主要来自AS请求认证。AS 返回 使用用户主体 的 Kerberos密码加密 的 TGT ，该密码仅为用户主体和 AS 所知。用户主体使用其 Kerberos 密码在本地解密TGT，从那时起，直到 ticket 到期，用户主体可以使用 TGT 从 TGS 获取服务票据。服务票证允许委托人访问服务。
Kerberos 简单来说就是一个用于安全认证第三方协议，它采用了传统的共享密钥的方式，实现了在网络环境不一定保证安全的环境下，client 和 server 之间的通信，适用于 client/server 模型，由 MIT 开发和实现。
Kerberos 服务是单点登录系统，这意味着您对于每个会话只需向服务进行一次自我验证，即可自动保护该会话过程中所有后续事务的安全。
由于每次解密 TGT 时群集资源（主机或服务）都无法提供密码，因此它们使用称为 keytab 的特殊文件，该文件包含资源主体的身份验证凭据。
Kerberos 服务器控制的主机，用户和服务集称为领域。
二、Kerberos验证过程
Kerberos 验证分为两个阶段：允许进行后续验证的初始验证以及所有后续验证自身。
1. 初始验证：票证授予票证
下图显示了如何进行初始验证：
- 客户端通过从密钥分发中心(Key Distribution Center, KDC)请票证授予票证(Ticket-Granting Ticket, TGT)开始 Kerberos 会话。此请求通常在登录时自动完成。 要获取特定服务的其他票证，需要 TGT 。票证授予票证类似于护照。与护照一样，TGT 可标识您的身份并允许您获取多个“签证”，此处的“签证”（票证）不是用于外国，而是用于远程计算机或网络服务。与护照和签证一样，票证授予票证和其他各种票证具有有限的生命周期。区别在于基于 Kerberos 的命令会通知您拥有护照并为您取得签证。您不必亲自执行该事务。 与票证授予票证类似的另一种情况是可以在四个不同的滑雪场使用的三天滑雪入场卷。只要入场券未到期，您就可以在决定要去的任意一个滑雪场出示入场卷，并获取该滑雪场提供的缆车票。获取缆车票后，即可在该滑雪场随意滑雪。如果第二天去另一个滑雪场，您需要再次出示入场卷，并获取新滑雪场的另一张缆车票。区别在于基于 Kerberos 的命令会通知您拥有周末滑雪入场卷，并会为您取得缆车票。因此，您不必亲自执行该事务。
- KDC 可创建 TGT ，并采用加密形式将其发送回客户端。客户端使用其口令来解密 TGT 。
- 拥有有效的 TGT，只要该 TGT 未到期，客户机便可以请求所有类型的网络操作（如 rlogin 或 telnet）的票证。此票证的有效期通常为一天。每次客户端执行唯一的网络操作时，都将从 KDC 请求该操作的票证。
2. 后续Kerberos验证
客户机收到初始验证后，每个后续验证都按下图所示的模式进行。
- 客户机通过向 KDC 发送其 TGT 作为其身份证明，从 KDC 请求特定服务（例如，远程登录到另一台计算机）的票证。
- KDC 将该特定服务的票证发送到客户机。
例如，假定用户
joe要访问已通过要求的krb5验证共享的 NFS 文件系统。由于该用户已经通过了验证（即，该用户已经拥有票证授予票证），因此当其尝试访问文件时，NFS 客户机系统将自动透明地从 KDC 获取 NFS 服务的票证。 例如，假定用户joe在服务器boston上使用 rlogin。由于该用户已经通过了验证（即，该用户已经拥有票证授予票证），所以在运行 rlogin 命令时，该用户将自动透明地获取票证。该用户使用此票证可随时远程登录到boston，直到票证到期为止。如果joe要远程登录到计算机denver，则需要按照步骤 1 获取另一个票证。 - 客户机将票证发送到服务器。 使用 NFS 服务时，NFS 客户机会自动透明地将 NFS 服务的票证发送到 NFS 服务器。
- 服务器允许此客户机进行访问。
从这些步骤来看，服务器似乎并未与 KDC 通信。但服务器实际上与 KDC 进行了通信，并向 KDC 注册了其自身，正如第一台客户机所执行的操作。为简单起见，该部分已省略。
关于 Kerberos 更多的原理讲解可参考以下链接，对理解 Kerberos 原理也很有帮助：
- https://www.zhihu.com/question/22177404/answer/492680179
- https://www.anquanke.com/post/id/171552#h2-2
三、Kerberos基本概念
1. Key Distribution Center, or KDC
在启用Kerberos的环境中进行身份验证的受信任源。
2. Kerberos KDC Server
作为密钥分发中心（KDC）的计算机或服务器。
3. Kerberos Client
集群中针对KDC进行身份验证的任何计算机。
4. KDC Admin Account
Ambari用于在KDC中创建主体并生成密钥表的管理帐户。
5. Principal
Kerberos principal（又称为主体）用于在kerberos加密系统中标记一个唯一的身份。主体可以是用户（如joe）或服务（如namenode或hive）。
根据约定，主体名称分为三个部分：主名称、实例和领域。例如，典型的Kerberos主体可以是joe/admin@EXAMPLE.COM。在本实例中：
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。由于服务未使用密码登录以获取其票证，因此其主体的身份验证凭据存储在keytab密钥表文件中，该文件从Kerberos数据库中提取并本地存储在服务组件主机上具有服务主体的安全目录中。比如NameNode组件在node1.example.com主机上，启用kerberos之后，会自动生成nn.service.keytab文件，并存储在/etc/security/keytabs目录下，用户所有者是hdfs:hadoop，权限为400，如图所示：
ambari 和 hadoop service 的 principals 都存储 Kerberos KDC 中，如下图所示：
Principal和Keytab命名约定
惯例 | 示例 | |
|---|---|---|
Principals | $service_component_nam/$FQDN@EXAMPLE.COM | nn/node1.example.com@EXAMPLE.COM |
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 身份验证器恰好具有相同的时间戳，则身份验证将作为重播请求被拒绝。
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 进行身份验证。 |
6. realms name
包含 KDC 和许多客户端的 Kerberos 网络，类似于域，俗称为领域。
7. keytab
keytab 是包含 principals 和加密 principal key 的文件。
keytab 文件对于每个 host 是唯一的，因为 key 中包含 hostname 。keytab 文件用于不需要人工交互和保存纯文本密码，实现到 kerberos 上验证一个主机上的 principal 。
因为服务器上可以访问 keytab 文件即可以以 principal 的身份通过 kerberos 的认证，所以，keytab 文件应该被妥善保存，应该只有少数的用户可以访问。
8. ticket（票证）
ticket 是一种信息包，用于将用户身份安全地传递到服务器或服务。一个票证仅对一台客户机以及某台特定服务器上的一项特殊服务有效。票证包含以下内容：
- 服务的主体名称
- 用户的主体名称
- 用户主机的 IP 地址
- 时间标记
- 定义票证生命周期的值
- 会话密钥的副本
所有此类数据都使用服务器的服务密钥进行加密。颁发票证之后，可重用票证直到期为止。
9. credential（凭证）
是一种信息包，其中包含票证和匹配的会话密钥。凭证使用发出请求的主体的密钥进行加密。通常，KDC 会生成凭证以响应客户机的票证请求。
10. authenticator（验证者）
是服务器用于验证客户机用户主体的信息。验证者包含用户的主体名称、时间标记和其他数据。与票证不同，验证者只能使用一次，通常在请求访问服务时使用。验证者使用客户机和服务器共享的会话密钥进行加密。通常，客户机会创建验证者，并将其与服务器或服务的票证一同发送，以便向服务器或服务进行验证。
四、票证生命周期
每当主体获取包括票证授予票证 (Ticket–Granting Ticket, TGT) 在内的票证时，可以通过 kinit 的 -l 选项指定的生命周期值，前提是使用 kinit 获取票证。缺省情况下，kinit 使用最长生命周期值。kdc.conf 文件中指定的最长生命周期值 (max_life)。
可通过 kinit 的 -r 选项指定的可更新生命周期值，前提是使用 kinit 获取或更新票证。kdc.conf 文件中指定的最长可更新生命周期值 (max_renewable_life)。
五、Kerberos主体名称
每个票证都使用主体名称进行标识。主体名称可以标识用户或服务。以下是一些主体名称的示例：
主体名称 | 说明 |
|---|---|
username@EXAMPLE.COM | 用户的主体 |
username/admin@EXAMPLE.COM | admin 主体，可用于管理 KDC 数据库。 |
K/M@EXAMPLE.COM | 主密钥名称主体。一个主密钥名称主体可与每个主 KDC 关联。 |
krbtgt/EXAMPLE.COM@EXAMPLE.COM | 生成票证授予票证时使用的主体。 |
kadmin/host1.example.com@EXAMPLE.COM | 允许使用 kadmind 访问 KDC 的主 KDC 服务器的主体。 |
ambari-qa-xxx@EXAMPLE.COM | Ambari 用于执行服务“冒烟”检查并运行警报健康检查。 |
HTTP/host1.example.com@EXAMPLE.COM | 用于访问 Hadoop Web UI 时用到的 principal |
六、注意事项
1. 时钟同步
所有参与 Kerberos 验证系统的主机都必须在指定的最长时间（称为时钟相位差）内同步其内部时钟。针对这一要求，需要进行另一种 Kerberos 安全检查。如果任意两台参与主机之间的时间偏差超过了时钟相位差，则客户机请求会被拒绝。
时钟相位差的最大缺省值为 300 秒（5 分钟）。出于安全原因，不要将时钟相位差增大到超过 300 秒。
时钟同步设置方法：《Linux时钟同步(修订版)》
七、Kerberos的优点和不足
1. 优点
较高的Performance
虽然我们一再地说Kerberos是一个涉及到3方的认证过程：Client、Server、KDC。但是一旦Client获得用过访问某个Server的Ticket，该Server就能根据这个Ticket实现对Client的验证，而无须KDC的再次参与。和传统的基于Windows NT 4.0的每个完全依赖Trusted Third Party的NTLM比较，具有较大的性能提升。
实现了双向验证（Mutual Authentication）
传统的NTLM认证基于这样一个前提：Client访问的远程的Service是可信的、无需对于进行验证，所以NTLM不曾提供双向验证的功能。这显然有点理想主义，为此Kerberos弥补了这个不足：Client在访问Server的资源之前，可以要求对Server的身份执行认证。
互操作性（Interoperability）
Kerberos最初由MIT首创，现在已经成为一种被广泛接受的标准。所以对于不同的平台可以进行广泛的互操作。
2. 不足
- Kerberos身份认证采用的是对称加密机制，加密和解密使用的是相同的密钥，交换密钥时的安全性比较难以保障。
- Kerberos服务器与用户共享的服务会话密钥是用户的口令字，服务器在响应时不需验证用户的真实性，而是直接假设只有合法用户拥有了该口令字。如果攻击者截获了响应消息，就很容易形成密码攻击。
- Kerberos中的AS（身份认证服务）和TGS是集中式管理，容易形成瓶颈，系统的性能和安全也严重依赖于AS和TGS的性能和安全。在AS和TGS前应该有访问控制，以增强AS和TGS的安全。
- 随用户数量增加，密钥管理较复杂。Kerberos拥有每个用户的口令字的散列值，AS与TGS负责户间通信密钥的分配。假设有n个用户想同时通信，则需要维护n×（n-1）/2个密钥。
八、总结
本篇文章主要从 Kerberos 概述、验证过程的描述、基本概念的解释、Kerberos 注意事项及优缺点的方面来介绍 Kerberos 的。更多的 Kerberos 相关资料，可参考以下链接，建议都点开看看！
扩展链接
- 《Kerberos原理--经典对话》
- 《基于ambari的Kerberos安装配置》
- 《Windows本地安装配置Kerberos客户端》
- 《Kerberos实战》
- 《基于Ambari禁用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
