图解 Kerberos：身份认证
Kerberos 是一种身份认证协议，被广泛运用在大数据生态中，甚至可以说是大数据身份认证的事实标准。本文将详细说明 Kerberos 原理。
1.什么是 Kerberos ？
Kerberos 一词来源于古希腊神话中的 Cerberus —— 守护地狱之门的三头犬。下图是 Kerberos 的 LOGO。
一句话来说，Kerberos 是一种基于加密 Ticket 的身份认证协议。Kerberos 主要由三个部分组成：Key Distribution Center（KDC）、Client 和 Service。 大致关系如下图所示：
客户端会先访问两次 KDC，然后再访问目标 Service，如：HTTP 服务。
2.Kerberos 基本概念
2.1 基本概念
（1）Principal：大致可以认为是 Kerberos 世界的用户名，用于标识身份。Principal 主要由三部分构成：primary，instance（可选）和 realm。
- 包含
instance的Principal，一般会作为Server端的Principal，如：NameNode，HiverServer2，Presto Coordinator 等。 - 不含有
instance的Principal，一般会作为Client端的Principal，用于身份认证。
（2）Keytab：密码本。包含了多个 principal 与密码的文件，用户可以利用该文件进行身份认证。
（3）Ticket Cache：客户端与 KDC 交互完成后，包含身份认证信息的文件，短期有效，需要不断 renew。
（4）Realm：Kerberos 系统中的一个 namespace。不同 Kerberos 环境，可以通过 realm 进行区分。
2.2 KDC
Key Distribution Center（KDC），是 Kerberos 的核心组件，主要由三个部分组成：
- Kerberos Database：包含了一个 Realm 中所有的 Principal、密码与其他信息。（默认：Berkeley DB）
- Authentication Service（AS）：进行用户信息认证，为客户端提供
Ticket Granting Tickets（TGT）。 - Ticket Granting Service（TGS）：验证 TGT 与 Authenticator，为客户端提供
Service Tickets。
3.Kerberos 原理
在深入了解 Kerberos 原理之前，先介绍一下 Kerberos 协议的几个大前提，帮助大家理解：
- Kerberos 基于 Ticket 实现身份认证，而非密码。如果客户端无法利用本地密钥，解密出 KDC 返回的加密 Ticket，认证将无法通过。
- 客户端将依次与 Authentication Service，Ticket Granting Service 以及目标 Service 进行交互，共三次交互。
- 客户端与其他组件交互都将获取到两条信息，其中一条可以通过本地密钥解密出，另外一条将无法解密出。
- 户端想要访问的目标服务，将不会直接与 KDC 交互，而是通过能否正确解密出客户端的请求来进行认证。
- KDC Database 包含有所有 Principal 对应的密码。
- Kerberos 中信息加密方式一般是对称加密（可配置成非对称加密）。
下面，我们将以客户端访问 HTTP 服务为例，解释整个认证过程。
3.1 客户端与 Authentication Service
第一步，客户端通过 kinit USERNAME 或其他方式，将 客户端 ID，目标 HTTP 服务 ID，网络地址（可能是多个机器的 IP 地址列表，如果想在任何机器上使用，则可能为空），以及 TGT 有效期的寿命 等信息发送给 Authentication Service。
第二步，Authentication Server 将检查客户端 ID 是否在 KDC 数据库中。
如果 Authentication Server 检查操作没有异常，那么 KDC 将随机生成一个 Key，用于客户端与 Ticket Granting Service（TGS）通信。这个 Key，一般被称为 TGS Session Key。随后 Authentication Server 将发送 两条信息 给客户端。示意图如下：
其中一条信息被称为 TGT，由 TGS 的密钥加密，客户端无法解密，包含 客户端 ID，TGS Session Key 等信息。
另一条信息由客户端密钥加密，客户端可以正常解密，包含 目标 HTTP 服务 ID，TGS Session Key 等信息。
第三步，客户端利用本地的密钥解密出第二条信息。如果本地密钥无法解密出信息，那么认证失败。示意图如下：
3.2 客户端与 Ticket Granting Service
这时候，客户端有了 TGT（由于本地没有 TGS 的密钥，导致无法解密出其数据）与 TGS Session Key。
第四步，客户端将:
- 将 AS 发送过来的 TGT（由 TGS 密钥加密）转发给 TGS。
- 将包含自身信息的 Authenticator （由 TGS Session Key 加密）发送给 TGS。
第五步，TGS 将利用自身的密钥从 TGT 中解密出 TGS Session Key，然后利用 TGS Session Key 从 Authenticator 中解密出客户端的信息。
TGS 解密出所有信息后，将进行身份检查，进行认证：
- 将客户端 ID 与 TGT 的客户端 ID 进行比较。
- 比较来自 Authenticator 的时间戳和 TGT 的时间戳（典型的 Kerberos 系统的容忍度是 2 2 2 分钟，但也可以另行配置）。
- 检查 TGT 是否过期。
- 检查 Authenticator 是否已经在 TGS 的缓存中（为了避免重放攻击）。
当所有检查都通过后， TGS 随机生成一个 Key 用于后续客户端与 HTTP 服务交互时进行通信加密使用，即 HTTP Session Key。同样地，TGS 将发送 两条信息 给客户端：其中一条是 HTTP Ticket，由 HTTP 服务的密钥进行加密；另一条则由 TGS Session Key 加密，包含了客户端信息与时间戳。
第六步，客户端将利用 TGS Session Key 解密出其中一条信息，另一条信息由于是由目标 HTTP 服务加密，无法解密。
3.3 客户端与 HTTP Service
这时候，客户端有了 HTTP Ticket（由于本地没有 HTTP 服务的密钥，导致无法解密出其数据）与 HTTP Service Session Key。
第七步，客户端将:
- 将 TGS 发送过来的 HTTP Ticket（由 HTTP 密钥加密）转发给目标 HTTP 服务。
- 将包含自身信息的 Authenticator（由 HTTP Service Session Key 加密）发送给 HTTP 服务。
注：上图中 Ticket for HTTP Service 中装的应该是 HTTP Service Session Key，而不是 TGS Session Key，有一点小错误，注意甄别。
第八步，HTTP 服务首先利用自身的密钥解密出 HTTP Ticket 的信息，得到 HTTP Service Session Key；随后，利用 HTTP Service Session Key 解密出用户的 Authenticator 信息。
信息解密完成后，HTTP 服务同样需要做一些信息检查：
- 将 Authenticator 中的客户端 ID 与 HTTP Ticket 中的客户端 ID 进行比较。
- 比较来自 Authenticator 的时间戳和 HTTP Ticket 的时间戳（典型的 Kerberos 系统对差异的容忍度是 2 2 2 分钟，但也可以另行配置）。
- 检查 Ticket 是否过期。
- 检查 Authenticator 是否已经在 HTTP 服务器的缓存中（为了避免重放攻击）。
然后，HTTP 服务会发送包含其 ID 和时间戳的身份验证器消息，以便向您确认其身份，并使用 HTTP Service Session Key 进行加密。
您的机器通过使用缓存的 HTTP Service Session Key 解密来读取身份验证器消息，并知道它必须接收带有 HTTP 服务 ID 和时间戳的消息。
现在，您已通过身份验证，可以使用 HTTP 服务。未来的请求将使用缓存的 HTTP Service Ticket，只要它没有按照生命周期属性中的定义过期即可。
参考如下：