1.1 What is Kerberos
1.1.1 简单介绍
Kerberos是一个用于鉴定身份（authentication）的协议， 它采取对称密钥加密（symmetric-key cryptography），这意味着密钥不会在网络上传输。在Kerberos中，未加密的密码（unencrypted password）不会在网络上传输，因此攻击者无法通过嗅探网络来偷取用户的密码。
Kerberos利用对称加密和受信任的第三方（即KDC, key distribution center）来鉴别要求使用网络服务的用户的身份。所有有KDC和secondary KDC管理的主机构成了一个域（realm）。
当一个用户的身份通过了KDC的验证后，KDC会向该用户发送一个证书/票据（该证书/票据是与这次会话绑定的），其他kerberized services会在该用户的主机上搜索该ticket，而不是要求用户使用密码来验证他的身份。
1.1.2 关于Kerberos的一些概念
Principal
一个用户会以一个独一无二的身份来被KDC认证，该身份被称为principal。一个Principal由三个部分组成：primary, instance以及realm，其组成形式为primary/instance@realm。
primary : 可以是OS中的username，也可以是service name；
instance : 用于区分属于同一个user或者service的多个principals，该项为optional；
realm : 类似于DNS中的domain，定义了一组principals
1.1.3 认证过程
1、当用户在一个kerberos-aware网络中登录到他的workstation之后，authentication server将向KDC发送一个TGT请求（a request for a ticket-granting ticket），而他的principal将作为其中的组成部分。该请求可以由登录程序来负责发送（这样该过程对用户透明），也可以在用户登录后通过执行kinit来发送。
2、KDC在其数据库中检查该pricipal。
3、如果找到了该principal，则KDC将创建一个TGT，并用user key进行加密，然后将加密后的TGT发送给该用户。这里，user key并不是用户的密码，而是由用户密码计算而来（例如hash）。
4、用户所在主机的Kerberos client的登录程序或者kinit程序在收到加密的TGT后，用该用户的user key进行解密。user key只会在client主机上被使用，绝不会在网络上传输。KDC发送的ticket将被保存在一个本地文件中（credentials cache），它可以被kerberized services查验。
5、用户的身份验证完成后，servers（运行着kerberized applciations & services）可以查验被识别的principals及其keys（这将被保存在keytab中），而不必用kinit来查验。
TGT有一个可设定的失效期（通常为10~24小时），这会被保存在client所在主机的credential cache中。在ticket过期之前，用户在请求kerberized services的服务时不需要再次输入用户密码，除非他们登出后再登录。
每当用户需要访问一个network service时，client会利用TGT向TGS（ticket-granting server）请求获得针对该特定网络服务的一个新的ticket。之后，用户可以利用该service ticket来向该network service实现authentication。
1.1.4 How Kerberos works
KDC就是受信任的第三方（trusted third party arbitrator），KDC上运行着2个重要的Kerberos daemons，即 kadmind 和 krb5kdc。
Kadmind: 这是管理Kerberos server的进程，一个名为kadmin 的程序使用 kadmind 来维护principal database和policy configuration。
Krb5kdc: 在Kerberos authentication的过程中担负trusted third party arbitrator的职责。
1.2 认证原理
1.2.1 知识准备
为了使读者更加容易理解，在这里我们先给出两个重要的概念：
▪ Long-term Key/Master Key：在Security的领域中，有的Key可能长期内保持不
变，比如你在密码，可能几年都不曾改变，这样的Key、以及由此派生的Key被称为Long-term Key。对于Long-term Key的使用有这样的原则：被Long-term Key加密的数据不应该在网络上传输。原因很简单，一旦这些被Long-term Key加密的数据包被恶意的网络监听者截获，在原则上，只要有充足的时间，他是可以通过计算获得你用于加密的Long-term Key的——任何加密算法都不可能做到绝对保密。
在一般情况下，对于一个Account来说，密码往往仅仅限于该Account的所有者知晓，甚至对于任何Domain的Administrator，密码仍然应该是保密的。但是密码却又是证明身份的凭据，所以必须通过基于你密码的派生的信息来证明用户的真实身份，在这种情况下，一般将你的密码进行Hash运算得到一个Hash code, 我们一般管这样的Hash Code叫做Master Key。由于Hash Algorithm是不可逆的，同时保证密码和Master Key是一一对应的，这样既保证了你密码的保密性，又同时保证你的Master Key和密码本身在证明你身份的时候具有相同的效力。
▪ Short-term Key/Session Key：由于被Long-term Key加密的数据包不能用于网络传送，所以我们使用另一种Short-term Key来加密需要进行网络传输的数据。由于这种Key只在一段时间内有效，即使被加密的数据包被黑客截获，等他把Key计算出来的时候，这个Key早就已经过期了。
1.2.2 认证详细原理
Kerberos实际上一个基于Ticket的认证方式。Client想要获取Server端的资源，先得通过Server的认证；而认证的先决条件是Client向Server提供从KDC获得的一个有Server的Master Key进行加密的Session Ticket（Session Key + Client Info）。可以这么说，Session Ticket是Client进入Server领域的一张门票。而这张门票必须从一个合法的Ticket颁发机构获得，这个颁发机构就是Client和Server双方信任的KDC，同时这张Ticket具有超强的防伪标识：它是被Server的Master Key加密的。对Client来说，获得Session Ticket是整个认证过程中最为关键的部分。
为了更好的说明整个Ticket Distribution的过程，我在这里做一个类比。现在的股事很火爆，上海基本上是全民炒股，我就举一个认股权证的例子。有的上市公司在股票配股、增发、基金扩募、股份减持等情况会向公众发行认股权证，认股权证的持有人可以凭借这个权证认购一定数量的该公司股票，认股权证是一种具有看涨期权的金融衍生产品。
而我们今天所讲的Client获得Ticket的过程也和通过认股权证购买股票的过程类似。如果我们把Client提供给Server进行认证的Ticket比作股票的话，那么Client在从KDC那边获得Ticket之前，需要先获得这个Ticket的认购权证，这个认购权证在Kerberos中被称为TGT：Ticket Granting Ticket，TGT的分发方仍然是KDC。
我们现在来看看Client是如何从KDC处获得TGT的：首先Client向KDC发起对TGT的申请，申请的内容大致可以这样表示：“我需要一张TGT用以申请获取用以访问所有Server的Ticket”。KDC在收到该申请请求后，生成一个用于该Client和KDC进行安全通信的Session Key（SKDC-Client）。为了保证该Session Key仅供该Client和自己使用，KDC使用Client的Master Key和自己的Master Key对生成的Session Key进行加密，从而获得两个加密的SKDC-Client的Copy。对于后者，随SKDC-Client一起被加密的还包含以后用于鉴定Client身份的关于Client的一些信息。最后KDC将这两份Copy一并发送给Client。这里有一点需要注意的是：为了免去KDC对于基于不同Client的Session Key进行维护的麻烦，就像Server不会保存Session Key（SServer-Client）一样，KDC也不会去保存这个Session Key（SKDC-Client），而选择完全靠Client自己提供的方式。
通过上面的过程，Client实际上获得了两组信息：一个通过自己Master Key加密的Session Key，另一个被Sever的Master Key加密的数据包，包含Session Key和关于自己的一些确认信息。
Client通过自己的Master Key对KDC加密的Session Key进行解密从而获得Session Key，随后创建Authenticator（Client Info + Timestamp）并用Session Key对其加密。最后连同从KDC获得的、被Server的Master Key加密过的数据包（Client Info + Session Key）一并发送到Server端。我们把通过Server的Master Key加密过的数据包称为Session Ticket。
当Server接收到这两组数据后，先使用他自己的Master Key对Session Ticket进行解密，从而获得Session Key。随后使用该Session Key解密Authenticator，通过比较Authenticator中的Client Info和Session Ticket中的Client Info从而实现对Client的认证。
1.2.3kafka认证过程
总结起来也很简单，Broker启动时，需要使用配置文件中的身份和密钥文件向KDC（Kerberos服务器）认证，认证通过则加入Kafka集群，否则报错退出。
Producer（或Consumer）启动后需要经过如下步骤与Broker建立安全的Socket连接：
1.Producer向KDC认证身份，通过则得到TGT（票证请求票证），否则报错退出
2.Producer使用TGT向KDC请求Kafka服务，KDC验证TGT并向Producer返回SessionKey（会话密钥）和ServiceTicket（服务票证）
3.Producer使用SessionKey和ServiceTicket与Broker建立连接，Broker使用自身的密钥解密ServiceTicket，获得与Producer通信的SessionKey，然后使用SessionKey验证Producer的身份，通过则建立连接，否则拒绝连接。