目录
Kerberos
Kerberos模型
三、Kerberos 基本概念
3.1 基本概念
3.2 KDC
四、Kerberos 原理
4.1 客户端与 Authentication Service
4.2 客户端与 Ticket Granting Service
4.3 客户端与 HTTP Service
五、Kerberos 的优势
Kerberos是一种计算机网络授权协议，用来在非安全网络中，对个人通信以安全的手段进行身份认证。这个词又指麻省理工学院为这个协议开发的一套计算机软件。
Kerberos
Kerberos 是一种基于加密 Ticket 的身份认证协议。Kerberos 主要由三个部分组成：Key Distribution Center (即KDC)、Client 和 Service。 大致关系如下图所示：
Kerberos模型
基于Needham-Schroeder的可信第三方协议，采用DES加密（也可用其他算法替代)，它与网络上的每个实体分别共享一个不同的秘密密钥，知道该秘密密钥就是身份的证明。
Kerberos有一个所有客户和秘密密钥的数据库，由于Kerberos知道每个人的秘密密钥，所以它能产生一个实体证实另一个实体身份的消息。Kerberos还能产生会话密钥，只供一个客户机和一个服务器(或两个客户机)使用。会话密钥用来加密双方间的通信消息，通信完毕，即销毁会话密钥。
Kerberos 协议如下：
-
客户从Kerberos 请求一张票据许可票据（TGT，Ticket Granting Ticket）作为票据许可服务(TGS，Ticket-Granting Service），该票据用用户的秘密密钥加密后发送给用户；
-
为了使用特定的服务器，客户需要从TGS中请求一张票据，TGS 将票据发回给客户；
-
客户将此票据提交给服务器和鉴别器，如果客户的身份没有问题，服务器就会让客户访问该服务。
三、Kerberos 基本概念
3.1 基本概念
- Principal：大致可以认为是 Kerberos 世界的用户名，用于标识身份。principal 主要由三部分构成：primary，instance(可选) 和 realm。包含 instance 的principal，一般会作为server端的principal，如：NameNode，HiverServer2，Presto Coordinator等；不含有 instance 的principal，一般会作为 客户端的principal，用于身份认证。例子如下图所示：
- Keytab："密码本"。包含了多个 principal 与密码的文件，用户可以利用该文件进行身份认证。
- Ticket Cache：客户端与 KDC 交互完成后，包含身份认证信息的文件，短期有效，需要不断renew。
- Realm：Kerberos 系统中的一个namespace。不同 Kerberos 环境，可以通过 realm 进行区分。
3.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。
四、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 服务为例，解释整个认证过程。
4.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等信息。
第三步，客户端利用本地的密钥解密出第二条信息。如果本地密钥无法解密出信息，那么认证失败。示意图如下：
4.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 中解密出客户端的信息。
4.3 客户端与 HTTP Service
这时候，客户端有了HTTP Ticket（由于本地没有HTTP服务的密钥，导致无法解密出其数据）与 HTTP Session Key。
第七步，客户端将:
- “无脑”将 AS 发送过来的 HTTP Ticket（由HTTP 密钥加密）转发给目标 http 服务。
- 将包含自身信息的Authenticator(由HTTP Session Key加密)发送给 http 服务。
五、Kerberos 的优势
- 密码无需进行网络传输。基于 Ticket 实现身份认证，保障密钥安全性。
- 双向认证。整个认证过程中，不仅需要客户端进行认证，待访问的服务也需要进行身份认证。
- 高性能。一旦Client获得用过访问某个Server的Ticket，该Server就能根据这个Ticket实现对Client的验证，而无须KDC的再次参与。
