Hadoop生态利用Kerberos认证机制来识别可靠的服务和节点，保障Hadoop集群的安全，那么Kerberos到底是什么？为什么要选择它来进行认证？Kerberos认证的流程又是怎样的呢？让我们带着这些问题看一下这篇文章。
Kerberos是什么
Kerberos是一种网络认证协议，它作为一种可信任的第三方认证服务，通过对称加密的方式执行认证服务。为客户端、服务端的应用程序提供强大的、严谨的认证服务。
对称加密
举个栗子：
我们都知道数字有一些特殊的意义，比如：5=我 2=爱 1=你。你看上个姑娘叫小芳，你想向她表达爱慕之情但是又不想明说。 你：521 小芳：对不起你是个好人。
上面其实就是对称加密的一种方式，首先你和小芳都知道相同的加密算法即5=我 2=爱 1=你。然后你通过该加密算法将“我爱你”三个字加密后的结果521发送给小芳，小芳通过相同的加密算法（5=我 2=爱 1=你）进行解密，并给你发了一张好人卡。
对称加密：在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥。
那么对称加密有没有什么缺点呢？
举个栗子：
你又看上了小芳的朋友小丽，展开了新一波的攻势。 你：521 小丽：你上次跟小芳也是这么说的，你真不是个好人
缺点：由于对称加密需要双方都知道加密的密钥，那么持有相同密钥的人很容易对其他人的信息进行解密。
非对称加密
非对称加密比对称密钥相对来讲比较安全一些，为了不让小丽知道你给小芳说了什么，你们开始停止使用共同的密钥，这样就不会被小丽知道你和小芳说话的内容了。然后每个人生成一个“私钥”和一个“公钥”，通过公钥加密的信息可以利用私钥进行解密。私钥每个人自行进行保护，然后把公钥进行分享。
举个栗子：
你：小芳，你的公钥给我下，我给你看个宝贝。 小芳：“你怕是个傻子吧” 给你，这是我的公钥。 你：iwty 小芳：iwty经过私钥解密后得到内容我爱你。
非对称密钥看上去比对称密钥安全了不少，公钥随便给你，反正私钥在我手里，加密的信息通过私钥才能解密。这时候即使小丽拿到了你给小芳发的信息，她没有小芳的私钥也不知道说的是什么。
非对称加密：需要一对密钥，可公开的为公钥，私有保护的为私钥。其他用户通过该用户的公钥加密的消息，只能通过该用户的私钥进行解密。也就是说公开了其中公钥并不会造成什么影响。
那么非对称密钥就一定是安全的吗？再举个例子：
你：小芳，你的公钥给我下，我给你看个好宝贝。
小丽（冒充小芳）：“这是小丽的公钥”，这是小芳的公钥。
你：iwty
小丽：使用自己的私钥解密后得到我爱你的真实信息。
所以这时候，怎么证明你拿到的“小芳的公钥”就是小芳的公钥呢？
数字证书
前面说到，如何证明你拿到的“小芳的公钥”就是小芳的公钥。数字证书是什么意思呢，就是选择双方信任的第三方所颁发的一个认证标识。
举个例子：
你想对小芳表达爱慕之情，但是不要意思直接说，又怕被小丽知道。所以你找来了另外一个关键任务小明。你、小芳和小明之间进行了约定。小明把他的公钥给了你，并告诉你，他会将小芳的公钥信息用他的私钥进行加密，加密后给你，如果你可以用小明的公钥解开，那么这个就是真正的小芳的公钥，你就可以发信息了。
你：拿着小明给你的公钥，小芳，你公钥给我一下，我给你看个宝贝。
小芳：小明你帮我加密一下吧，然后发给了你
你：用小明的公钥解密了用小明私钥加密的小芳的公钥（这句有点绕），并确认是小芳的公钥，然后发送iwty
小芳：解密信息得到我爱你，并发了一张好人卡。
在上面的例子中，小明起到了关键性的作用，他证明了小芳是小芳，发给你的小芳的公钥没有被别人修改过。但是大家发现了什么没有，这里又有一个“小明的公钥”。那么谁来证明“小明的公钥”就是小明的公钥呢？
当然，这种都是可值得信赖的第三方机构充当小明的角色，比如我们所谓的注册中心RA和证书机构CA。但是需要注意的是，小明的角色也是可以被黑客黑掉的，黑客把小明的公钥（根证书）换成自己的，那么又可以为所欲为了。
Kerberos认证流程
终于到我们的主角Kerberos了，前面我们也提到了Kerberos是可信任的第三方，那么它与数字证书的颁发机构有什么不同呢？它是否可以被伪造，如何保证认证机制？
在举例之前呢，我们先来了解几个新名词：
principal(安全个体)：被Kerberos成功认证的个体，有一个名字和口令
Ticket：门票，用来向服务器证明自己的身份，包括标识、会话密钥、时间戳。
KDC(key distribution center ) : 是一个网络服务，提供ticket和临时会话密钥
AS (Authentication Server)： 认证服务器
TSG(Ticket Granting Server)： 许可证服务器
举个栗子，这里我尽可能的简化相关逻辑，便于理解：
你（Client）和小芳（Server）分别作为一个安全的个体，向KDC进行认证，添加你们的principal名称和密码。（密码你知,KDC知 所以是对称加密）
好，现在你想和小芳联系了，但是你要确认这个小芳是你想找的小芳。
你：hello KDC，我想联系下小芳，你把认证的session key给我吧。
KDC接收到请求之后，首先从数据库里面查找你的principal，确认你是一个认证过的安全个体。然后将一个session key进行加密，注意，这里的session key有两份，一份是由你的密钥加密的，一份是由小芳的密钥加密的。它把两份都给了你。
注意思考，这里为什么要把小芳密钥加密后的session key也给你（1. 这样kdc不用维护session key的列表 2. kdc直接发送给小芳不一定可达）
你：你接收到两个session key，我们简化为Ckey（client 加密的key）和Skey（Server 加密的key）。这时候你用你自己的密钥，解开了Ckey。为了表明是你现在想与小芳说话而不是别人监听破解你的key而发送消息，这时候需要引入一个时间戳（认证时一个可接受的时间范围，时间间隔太长认为不安全，则server端不予处理）
这时候你把你的个人信息（ClientInfo）+时间戳 通过解密后的Ckey（kdc给你的session key）加密，加上Skey 发送给小芳。
小芳：小芳接收到你的消息，首先用自己的密钥解开Skey，获取到session key。再利用session key解密你发送的个人信息+时间戳。通过对比时间戳，发现时间在可控范围内，则认为你是安全的个体。可以进行通话。
你：而这个时候你可能也有点慌，这是不是小芳啊？别又是小丽。你想认证一下小芳怎么办呢？你需要把上一步的个人信息+时间戳利用session key进行加密，加上Skey和一个需要Server认证的flag即可。
小芳：小芳接收到你的消息，首先用自己的密钥解开Skey，获取到session key，再利用session key解密你发送的个人信息+时间戳。如果你需要认证，flag=true。则把你发送的时间戳用session key加密后发送给你。
你：接收到小芳发来的消息，用session key进行解密，发现与之前的时间戳一致。则验证是小芳而不是小丽。（这部分呢就是双向认证）
那么Kerberos比上面的流程要稍微复杂一点：
- Client作为一个安全个体认证到KDC之后，KDC会分发一个Ticket认购权证称为TGT（或者描述为Client连接KDC的密钥，经过KDC的Key加密过），需要注意的是TGT有时间限制，过期后需要重新向KDC获取，这样也保障了一定的安全性。
- Client要与Server进行通信则首先用TGT从KDC获得一个可以访问某一服务的Ticket（Session Key+Client Info）。这个Ticket是认证过程中最重要的一环，它的颁发机构就是双方可信的KDC，KDC对TGT解密认证，分发Ticket。
- Client向Server提交Ticket，Server接受到Ticket之后，对Ticket进行解密，验证时间戳。如需双方验证则发送加密时间戳到Client进行验证，验证成功后Client可以访问Server。
Kerberos认证这部分确实比较复杂，可以对照图例多过两遍。那么Kerberos都有哪些优点？我们来总结一下
- 安全可靠：Kerberos实现了双向认证
- 性能高：虽然Kerberos的认证需要Client Server 和 KDC三方认证，但是Client获取到Ticket之后（Ticket未过期），就可以直接与Server进行认证而不需要KDC的参与。
- 支持HA高可用，且成为被广泛接收的标准。支持不同平台进行操作。
参考
若有收获，就点个赞吧
0 人点赞
