【大数据安全-Kerberos】一篇文章搞定Kerberos认证

古城微笑少年丶 2023-10-08 20:31 85阅读 0赞

#### 【大数据安全-Kerberos】一篇文章搞定Kerberos认证 ####

*  1）Kerberos 相关了解
 *  2）Kerberos 基本概念
 *   *  2.1.基本概念
     *  2.2.KDC
 *  3）Kerberos 原理
 *   *  3.1.客户端 与 Authentication Service
     *  3.2.客户端 与 Ticket Granting Service
     *  3.3.客户端 与 HTTP Service
 *  4）Kerberos 优势

## 1）Kerberos 相关了解 ##

Kerberos 一词来源于古希腊神话中的 Cerberus —— 守护地狱之门的三头犬。下图是 Kerberos 的 LOGO:

![在这里插入图片描述][3022cdbacb8f475a8957c6c35dd4c377.png_pic_center]

Kerberos 是一种身份认证协议，被广泛运用在大数据生态中，甚至可以说是大数据身份认证的事实标准。

一句话来说，Kerberos 是一种基于加密 Ticket 的身份认证协议。Kerberos 主要由三个部分组成：Key Distribution Center （即KDC）、Client 和 Service。 大致关系如下图所示：

![在这里插入图片描述][9dd0d8cc63f248b88352a95e125f82ae.png]

客户端会先访问两次KDC，然后再访问目标Service，如：HTTP服务。

## 2）Kerberos 基本概念 ##

### 2.1.基本概念 ###

*  `Principal`：
    
    大致可以认为是 Kerberos 世界的用户名，用于标识身份。
    
    principal 主要由三部分构成：primary，instance（可选）和 realm。
    
    包含 instance 的 principal，一般会作为 server 端的 principal，如：NameNode，HiverServer2，Presto Coordinator 等；不含有 instance 的 principal，一般会作为 客户端的 principal，用于身份认证。
    
    例子如下图所示：
    
    ![在这里插入图片描述][d1f0b42f41244d9880a039ea1178fa62.png]
 *  `Keytab`：
    
    “密码本”。包含了多个 principal 与密码的文件，用户可以利用该文件进行身份认证。
 *  `Ticket Cache`：
    
    客户端与 KDC 交互完成后，包含身份认证信息的文件，短期有效，需要不断renew。
 *  `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 协议的几个大前提，帮助大家理解：

1、Kerberos 基于 Ticket 实现身份认证，而非密码。如果客户端无法利用本地密钥，解密出 KDC 返回的加密 Ticket，认证将无法通过。

2、客户端将依次与 Authentication Service, Ticket Granting Service 以及目标 Service 进行交互，共三次交互。

3、客户端与其他组件交互是，都将获取到两条信息，其中一条可以通过本地密钥解密出，另外一条将无法解密出。

4、客户端想要访问的目标服务，将不会直接与 KDC 交互，而是通过能否正确解密出客户端的请求来进行认证。

5、KDC Database 包含有所有 principal 对应的密码。

6、Kerberos 中信息加密方式一般是对称加密（可配置成非对称加密）。

下面，我们将以客户端访问 http 服务为例，解释整个认证过程。

### 3.1.客户端 与 Authentication Service ###

**第一步：**

客户端通过 kinit USERNAME 或其他方式，将客户端 ID，目标 HTTP 服务 ID，网络地址（可能是多个机器的 IP 地址列表，如果想在任何机器上使用，则可能为空），以及 TGT 有效期的寿命等信息发送给 Authentication Service。

![在这里插入图片描述][9127849210284c82b669a20ea209f439.png]  
**第二步：**

Authentication Server 将检查客户端 ID 是否在 KDC 数据库中。

![在这里插入图片描述][7a47fb40532642af911322847d2e86ab.png]

如果 Authentication Server 检查操作没有异常，那么 KDC 将随机生成一个 key，用于客户端与 Ticket Granting Service（TGS） 通信。这个Key，一般被称为 TGS Session Key。随后 Authentication Server 将发送两条信息给客户端。示意图如下：

![在这里插入图片描述][1d17c814645747199e32f1230272df24.png]

其中一条信息被称为 TGT ，由 TGS 的密钥加密，客户端无法解密，包含客户端 ID, TGS Session Key 等信息。另一条信息由客户端密钥加密，客户端可以正常解密，包含目标 HTTP 服务 ID，TGS Session Key 等信息。

**第三步：**

客户端利用本地的密钥解密出第二条信息。如果本地密钥无法解密出信息，那么认证失败。示意图如下：

![在这里插入图片描述][acdf0ea40b984a3584d2c9a384d77171.png]

### 3.2.客户端 与 Ticket Granting Service ###

**第四步（客户端）:**

这时候，客户端有了 TGT（由于本地没有 TGS 的密钥，导致无法解密出其数据）与 TGS Session Key。

*  “无脑”将 AS 发送过来的 TGT（由TGS密钥加密）转发给 TGS
 *  将包含自身信息的 Authenticator（由 TGS Session Key 加密）发送给 TGS

![在这里插入图片描述][8b83c6413b5e4410b00311b541e6397f.png]

**第五步：**

TGS 将利用 自身的密钥从 TGT 中解密出 TGS Session Key，然后利用TGS Session Key 从Authenticator 中解密出客户端的信息。

![在这里插入图片描述][0e413ffcfc314c098e35df43ca94f356.png]

TGS 解密出所有信息后，将进行身份检查，进行认证：

*  将客户端 ID 与 TGT 的客户端 ID 进行比较
 *  比较来自 Authenticator 的时间戳和 TGT 的时间戳 (典型的Kerberos系统的容忍度是2分钟，但也可以另行配置)
 *  检查 TGT 是否过期
 *  检查 Authenticator 是否已经在 TGS 的缓存中（为了避免重放攻击）

当所有检查都通过后， TGS 随机生成一个 Key 用于后续客户端与 HTTP 服务交互时进行通信加密使用，即 HTTP Session Key。同样地，TGS 将发送两条信息给客户端: 其中一条是 HTTP Ticket，由 HTTP 服务的密钥进行加密；另一条则由 TGS Session Key 加密，包含了客户端信息与时间戳。

![在这里插入图片描述][a094e97900ef415b81a3b65e9072686a.png]

**第六步：**

客户端将利用 TGS Session Key 解密出其中一条信息，另一条信息由于是由目标 HTTP 服务加密，无法解密。

![在这里插入图片描述][40c4efeace7646e79d2c7b971b904213.png]

### 3.3.客户端 与 HTTP Service ###

**第七步（客户端）:**

这时候，客户端有了 HTTP Ticket（由于本地没有 HTTP 服务的密钥，导致无法解密出其数据）与 HTTP Session Key。

*  “无脑”将 AS 发送过来的 HTTP Ticket（由 HTTP 密钥加密）转发给目标 http 服务。
 *  将包含自身信息的 Authenticator（由 HTTP Session Key 加密）发送给 http 服务。

![在这里插入图片描述][a4010dc9568a487c9556d23c8cc6c3d0.png]

**第八步：**

HTTP 服务首先利用自身的密钥解密出 HTTP Ticket 的信息，得到 HTTP Session Key；随后，利用 HTTP Session Key 解密出用户的 Authenticator 信息。

![在这里插入图片描述][a338cfd9d8974b69932e5ab9c0854fc1.png]  
信息解密完成后，HTTP 服务同样需要做一些信息检查：

*  将 Authenticator 中的客户端 ID 与 HTTP Ticket 中的客户端ID进行比较
 *  比较来自 Authenticator 的时间戳和 HTTP Ticket 的时间戳（典型的 Kerberos 系统对差异的容忍度是 2 分钟，但也可以另行配置）
 *  检查Ticket是否过期
 *  检查 Authenticator 是否已经在 HTTP 服务器的缓存中（为了避免重播攻击）

至此，所有的认证过程通过，客户端即可与远程 HTTP 服务完成了身份认证，可以进行后续的信息通信。

![在这里插入图片描述][8f3cb2cce3884325ba585d72c0d815c0.png]

## 4）Kerberos 优势 ##

1、密码无需进行网络传输。基于 Ticket 实现身份认证，保障密钥安全性。

2、双向认证。整个认证过程中，不仅需要客户端进行认证，待访问的服务也需要进行身份认证。

3、高性能。一旦Client获得用过访问某个 Server 的 Ticket ，该 Server 就能根据这个 Ticket 实现对 Client 的验证，而无须 KDC 的再次参与。

[3022cdbacb8f475a8957c6c35dd4c377.png_pic_center]: https://img-blog.csdnimg.cn/3022cdbacb8f475a8957c6c35dd4c377.png#pic_center
[9dd0d8cc63f248b88352a95e125f82ae.png]: https://img-blog.csdnimg.cn/9dd0d8cc63f248b88352a95e125f82ae.png
[d1f0b42f41244d9880a039ea1178fa62.png]: https://img-blog.csdnimg.cn/d1f0b42f41244d9880a039ea1178fa62.png
[9127849210284c82b669a20ea209f439.png]: https://img-blog.csdnimg.cn/9127849210284c82b669a20ea209f439.png
[7a47fb40532642af911322847d2e86ab.png]: https://img-blog.csdnimg.cn/7a47fb40532642af911322847d2e86ab.png
[1d17c814645747199e32f1230272df24.png]: https://img-blog.csdnimg.cn/1d17c814645747199e32f1230272df24.png
[acdf0ea40b984a3584d2c9a384d77171.png]: https://img-blog.csdnimg.cn/acdf0ea40b984a3584d2c9a384d77171.png
[8b83c6413b5e4410b00311b541e6397f.png]: https://img-blog.csdnimg.cn/8b83c6413b5e4410b00311b541e6397f.png
[0e413ffcfc314c098e35df43ca94f356.png]: https://img-blog.csdnimg.cn/0e413ffcfc314c098e35df43ca94f356.png
[a094e97900ef415b81a3b65e9072686a.png]: https://img-blog.csdnimg.cn/a094e97900ef415b81a3b65e9072686a.png
[40c4efeace7646e79d2c7b971b904213.png]: https://img-blog.csdnimg.cn/40c4efeace7646e79d2c7b971b904213.png
[a4010dc9568a487c9556d23c8cc6c3d0.png]: https://img-blog.csdnimg.cn/a4010dc9568a487c9556d23c8cc6c3d0.png
[a338cfd9d8974b69932e5ab9c0854fc1.png]: https://img-blog.csdnimg.cn/a338cfd9d8974b69932e5ab9c0854fc1.png
[8f3cb2cce3884325ba585d72c0d815c0.png]: https://img-blog.csdnimg.cn/8f3cb2cce3884325ba585d72c0d815c0.png