看完您若是还不明白 Kerberos 原理，算我输！

时间 2020-02-07

标签看完若是还不明白 kerberos 原理繁體版

原文原文链接

系统环境html

操做系统：CentOS 6 或 CentOS 7
JDK 版本：1.8.0_151
Ambari 版本：2.6.1
HDP 版本：2.6.4.0

扩展连接node

1、Kerberos概述

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

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

它知道的用户和服务（称为主体）及其各自的 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 服务器控制的主机，用户和服务集称为领域。oracle

2、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 原理也颇有帮助：

3、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_name/$FQDN@EXAMPLE.COM	nn/node1.example.com@EXAMPLE.COM
Keytabs	$service_component_abbreviation.service.keytab	/etc/security/keytabs/nn.service.keytab

请注意前面的示例中每一个服务主体的主名称。这些主要名称（例如nn或hive）分别表明NameNode或Hive服务。每一个主要名称都附加了实例名称，即运行它的主机的FQDN。此约定为在多个主机（如DataNodes和NodeManager）上运行的服务提供惟一的主体名称。添加主机名用于区分，举例，来自DataNode A的请求与来自DataNode B的请求。这一点很重要，缘由以下：

一个 DataNode 的受损 Kerberos 凭据不会自动致使全部 DataNode 的 Kerberos 凭据受损。
若是多个 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（验证者）

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

4、票证生命周期

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

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

5、Kerberos主体名称

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

主体名称	说明
username@EXAMPLE.COM	用户的主体
username/admin@EXAMPLE.COM	admin 主体，可用于管理 KDC 数据库。
K/M@EXAMPLE.COM	主密钥名称主体。一个主密钥名称主体可与每一个<br />主 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

6、注意事项

1. 时钟同步

全部参与 Kerberos 验证系统的主机都必须在指定的最长时间（称为时钟相位差）内同步其内部时钟。针对这一要求，须要进行另外一种 Kerberos 安全检查。若是任意两台参与主机之间的时间误差超过了时钟相位差，则客户机请求会被拒绝。

时钟相位差的最大缺省值为 300 秒（5 分钟）。出于安全缘由，不要将时钟相位差增大到超过 300 秒。

时钟同步设置方法：点我

7、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的身份执行认证。

对Delegation的支持

Impersonation和Delegation是一个分布式环境中两个重要的功能。Impersonation容许Server在本地使用Logon 的Account执行某些操做，Delegation需用Server将logon的Account带入到另过一个Context执行相应的操做。NTLM仅对Impersonation提供支持，而Kerberos经过一种双向的、可传递的（Mutual 、Transitive）信任模式实现了对Delegation的支持。

互操做性（Interoperability）

Kerberos最初由MIT独创，如今已经成为一行被普遍接受的标准。因此对于不一样的平台能够进行普遍的互操做。

2. 不足

Kerberos身份认证采用的是对称加密机制，加密和解密使用的是相同的密钥，交换密钥时的安全性比较难以保障。
Kerberos服务器与用户共享的服务会话密钥是用户的口令字，服务器在响应时不需验证用户的真实性，而是直接假设只有合法用户拥有了该口令字。若是攻击者截获了响应消息，就很容易造成密码攻击。
Kerberos中的AS（身份认证服务）和TGS是集中式管理，容易造成瓶颈，系统的性能和安全也严重依赖于AS和TGS的性能和安全。在AS和TGS前应该有访问控制，以加强AS和TGS的安全。
随用户数量增长，密钥管理较复杂。Kerberos拥有每一个用户的口令字的散列值，AS与TGS负责户间通讯密钥的分配。假设有n个用户想同时通讯，则须要维护n×（n-1）/2个密钥。

8、总结

本篇文章主要从Kerberos概述、验证过程的描述、基本概念的解释、Kerberos注意事项及优缺点的方面来介绍Kerberos的，接下来会出一个如何在Kerberos环境下使用Hadoop服务的文章教程，让咱们一块儿期待吧，哈哈

扩展连接

参考资料

本文来自：微信公众号【大数据实战演练】。阅读更多精彩好文，欢迎关注微信公众号【大数据实战演练】。