安全系列之介绍Kerberos认证协议

前言

一直以来Kerberos都是应用广泛的强/集群安全/网络身份验证/协议，虽然讲解资料也不少，但和HDFS一样很少有讲通的，很多都是使用kerberos原始论文的概念直接塞给读者，造成很多概念闭塞难懂。或者是讲故事买门票坐火车，例子很好懂，但没有和技术结合起来。这篇会按照理解难度从易到难，划分为四个部分，试着解决上边的问题统一做一下总结。

前言

一，入门 · Kerberos介绍

Kerberos是Hadoop集群安全机制的最基础的部分，Kerberos协议是提供用户认证的协议，主要实现有MIT Kerberos, ApacheDs, Heimdal, Kerby以及Microsoft Active Directory。

所以这里Kerberos解决的问题是：大数据集群安全用户认证。

类比对接到现实生活中，解决的一个关键且需要消化的问题是“如何证明你是你”。日常生活中，我们可能是掏出公安局办理的身份证，就很简单解决这个问题。如果身份证丢失，就要跑去认证中心重新办理身份证，那时候证明你是你的方法可能是验指纹，验照片来证明你是你，如果我们没有你的任何身份信息，可能你就要面对很多麻烦。所以一个可靠安全的认证政策帮助你可以得到你的合法权益，那么Kerberos就是集群中用于用户认证的一套协议。

在计算机的世界，当一个Client去访问Server服务器上的某服务时，Server如何判断Client是否有权限来访问自己主机上的服务，同时保证在这个过程中的通讯内容即使被拦截或篡改也不影响通讯的安全性，我们要合理规范一套安全认证方式，这正是Kerberos解决的问题。

二，表面 · 理解Kerberos

Kerberos应用模型中有以下三个角色存在（其实安全认证模型一般也都是这样，大家要重点理解）：

访问服务的Client
提供服务的Server
KDC（Key Distribution Center）密钥分发中心

fig.1 Kerberos机制角色

站在kerberos角度重新阐释在这张图，两个主要部分：

1. KDC是密钥分发中心，在KDC内部也有两个部分分别是Authentication server认证中心和Ticket Granting Server票据授权中心

2. 对于KDC来说，KDC client的两个角色：client是用户一方，server是用户想要访问的服务,如HTTP服务，SQL服务

在Kerberos中Client是否有权限访问Server端的服务由KDC发放的票据来决定。

fig.2 kerberos大体实现流程

kerberos中client，server，KDC（包括AS和TGS）的大体实现流程如上图，AS认证中心负责认证用户信息并返回给用户的身份证明，票据发放中心TGS负责发放用于server认证的票据，client请求服务，server提供服务。

三，里面 · Kerberos实质

以上是kerberos的抽象原理，但只是表面，几乎所有的安全认证都会走相似的逻辑，所以重要的不是以上的kerberos是什么，而是以下的kerberos怎么更细致实现的？

在kerberos中，当Client想要访问Server上的某个服务时，需要先向AS证明自己的身份，然后通过AS发放的TGT向Server发起认证请求，这个过程分为三块，每块有两个阶段：我们这里用图会用原图讲

fig.3 kerberos讲解图

这张图首先要熟悉好，分清表明的是内部调用还是外部调用，是加密区域还是没加密，是哪个区域加密的，官方的图比其余各种讲解图都要详细。

1. The Authentication Service Exchange：Client与AS的交互（AS_REQUEST，AS_REPLY)

fig.4 kerberos身份验证过程

第一阶段，client和KDC的AS交互拿身份证明，首先client发送AS_REQUEST阶段，我们可以看到在client端通过function把密码转成密钥，然后把身份信息，操作系统的时间戳，krb5的kerberos配置包装成AS_REQUEST报文发给AS。AS接收后提取信息并通过自己的配置和密钥来加密一份TGT（包装着client的身份信息和session密钥等），然后再拿这份TGT和client的密钥加密AS_REPLY报文传给client，注意AS_REPLY这份报文的加密区域。client接收AS_REPLY后可以用自己的密钥解开session key，krbtgt身份信息和一些公开配置信息，也就是证明自己通过AS认证的身份。而被KDC加密的这份TGT存到缓存中。

2. The Ticket-Granting Service (TGS) Exchange：Client与TGS的交互(KRB_TGS_REQ，KRB_TGS_REP）

ok，有了TGT，现在client可以证明“我是我”了

fig.5 kerberos服务请求访问过程

第二阶段，client使用上次session的短期密钥加密了自己的身份信息，把它和KDC加密的TGT以及基础信息一起包装成TGS请求报文，发给KDC的TGS（就是票据授权中心，概念比较多，都是缩写）。票据授权中心TGS收到TGS_REQUEST后，会执行检查client身份，检查TGT，然后生成新的session密钥。票据中心TGS这样拿着让client可授权访问的service密钥加密之前处理的信息成为一份TGS加密过的加密信息，然后把想暴露给client的信息写在外面包装成TGS_REPLY发回client。

client接收后取出自己可处理的信息，更换session key，然后准备请求服务。

3. The Client/Server Authentication Exchange：Client与Server的交互

第三阶段用户可以使用kerberos client通过service认证，并访问server的服务了。

fig.6 kerberos全貌

总结一下：

我们可以将Kerberos协议分为三个主要步骤：

1. 身份验证过程，其中client获取一个票证授予票证（TGT）作为身份验证令牌，

2，服务请求过程，其中client获取票证授予服务（TGS）以访问服务，

3. 服务访问，其中client使用TGS来验证和访问特定的服务

四，深入 · 重新认识Kerberos

现在我们可以了解并真正使用kerberos了，也会介绍一些概念帮你了解之前的内容

1. 安装

以上看到的client 和server以及配置都需要你自己去安装环境，各种操作系统下载方式各异可以自行百度下载krb5-admin-server krb5-kdc krb5-user krb5-config等kerberos必备的工具

2. 配置

/etc/krb5.conf

这个是kdc信息，kerberos客户端，以及调用kerberos api时的配置都会使用到，

[libdefaults]表示kerberos自带库中的参数默认

[realms] 你想配置的域
几个重要的配置项目包括：

ticket_lifetime：指定了kdc授权ticket的过期时长，默认24h，要求大于clockskew小于renew_lifetime

realms的section：指定了kdc和admin_server的路径

renew_lifetime：允许更新现有ticket的时长。

/etc/krb5kdc/kdc.conf

kdc的数据库等专属配置，可以根据自己的需求修改下kdc数据库的存放目录。

3. 时钟一致

配置kerberos要注意让域中各个节点时间一致，否则访问报文会带入其他节点的时间导致计算是kerberos抛错。

4. kerberos简单命令

kinit username // kerberos登陆

klist // 查看当前登陆信息

kadmin.local/kadmin // 进入kadmin

kdestroy //清除认证缓存（keytab或者密码登陆）

参考：

1. kerberos讲解：https://www.anquanke.com/post/id/171552#h3-5

2. kerberos官方：https://web.mit.edu/kerberos/

3. kerberos使用: https://www.jianshu.com/p/fc2d2dbd510b