文章作者：luxianghao
文章来源：http://www.cnblogs.com/luxianghao/p/5269739.html 转载请注明，谢谢合作。
免责声明：文章内容仅代表个人观点，如有不当，欢迎指正。
---
一，引言
Kerberos简单来说就是一个用于安全认证第三方协议，它采用了传统的共享密钥的方式，实现了在网络环境不一定保证安全的环境下，client和server之间的通信，适用于client/server模型，由MIT开发和实现。
Kerberos的神秘之处在于，它并不要求通信双方所在的网络环境是安全的，即使通信过程中数据被截取或者篡改依然不会影响它的正常工作，它提供的认证是双向的，不仅能保证Server不被错误的Client使用，同时也能保证Client不使用错误的Server。同时Kerberos又严重依赖于时间，时间戳也是Kerberos用来保证通信安全的重要手段，这个一般通过通信双方同时访问同一个时间服务器来实现。Kerberos也能达到单点登录的效果，即当Client通过了Kerberos server的认证后，便可以访问多个Real Server。
二，Kerberos原理浅析
在实际的应有场景中通常有三个角色，即需要访问服务的Client，提供服务的Application Server，以及提供安全认证的第三方Kerberos服务器KDC（Key Distribution Center）。它们彼此之间的认证、通信的数据流如下图所示。
仔细研究过上图之后，你可能会发现你能看明白的东西实在有限，而想要把Kerberos原理弄明白实在不是一件容易的事，不过可以庆幸的是Kerberos是用传统的共享密钥的方式实现的，这个概念对大家来说并不陌生，同时Kerberos认证还加了时间戳，有效时间，信息对比等伎俩，所以花时间细细读下来你依然能看明白，如果此时你就迫不及待的想研究的话你可以戳这里，这里，或者这里。现在，我们来讨论下Kerberos的认证的一个部分，我认为只要这个部分理解了，其他的都可以递推出来。如下图：
Client master key: KDC中存储的Client的密钥
Server master key: KDC中存储的Server的密钥
Sclient-Server：Client与Server之间的会话密钥
Client Info：记录了Client本身的Ip等基本信息
首先 Client询问KDC，我想访问某个Server，然后KDC会将会话密钥Sclient-Server用Client master key加密后传送给Client；与此同时，KDC也会将会话密钥Sclient-Server连同Client的基本信息打包用Server master key加密也发给Client，并经Client转发给Server，至此Client与KDC的交互完成。
然后，Client用自己的master key解密KDC传过来的第一个包，解密后获得会话密钥Sclient-Server，并用这个密钥加密自己的的信息和时间戳打包后传送给Server，此时Client开始和Server交互，如下图：
Server会收到两个数据包，一个用会话密钥加密，一个用自己的master key加密，Server先用自己的master key解密获取会话密钥和一份关于Client的信息，然后Server拿到解密后获取到的会话密钥再解开另外一个数据包，获得另一份关于Client的信息和时间戳，至此Client和Server的交互完成。
下面我们解释下这样传输数据的原因，为什么传递这些数据
1，上面有个数据包是KDC经Client转发给Server的，为什么不直接发给Server？
因为Server可能给多个Client提供服务，这样Server需要维护一个Client和会话密钥的对应表，这对Server是一个负担。
此外，因为网络传输的不确定性可能Client和Server并不能都及时获取到会话密钥，假如有一方获取失败，那么Client就不能访问Server
2，为什么要发两份关于Client的信息给Server？
通过这两份数据的对比，Server就能判断出是不是对的Client在访问服务。
3，Client是如何判断自己在访问对的Server呢？
因为Client给Server的一个数据包是用Server的master key来加密的所以只有对的Server才能解密。
4，为什么要用会话密钥
通信方的master key是长期有效的，如果在网络上传输，一旦被截取，理论上来说只要有足够的时间是可以破解的，所以我们才用临时的会话密钥来通信，一段时间后会话密钥会过期，同时时间戳也防止了，恶意用户重复使用同一个数据包。
5，为什么要用时间戳？
如果Client向Server传送的数据包被其他的Client截取，然后自己拿来向Server请求服务这，这样就会出问题，那么引入时间戳后，Server收到请求后将从解密后的数据包中获得的时间戳和当前时间对比，一旦超过一定范围将直接拒绝请求；所以，正如前面所说，Kerberos高度依赖时间同步服务。
事实上这个并不是Kerberos认证的整个过程，KDC实际上由AS和TGS两部分组成，你可以将TGS视作一个Server，然后还沿用上面所说的步骤来分析，这样就可以基本上梳理出Client访问Server的一个完整的过程了。
这些东西可能依然难于理解，你可以借助Kerberos经典会话中的场景来理解，请戳这里或者这里。
三，Kerberos应用
1，安装Kerberos，搭建Kerberos环境，用yum安装下列包即可
krb5-devel.x86_64
krb5-libs.x86_64
krb5-workstation.x86_64
krb5-server.x86_64 （仅server端需安装）
如果你想了解详细的安装步骤以及配置，请戳这里
这里我们仅贴出配置krb5.conf&kdc.conf中的主要部分
/etc/krb5.conf 中包含了realm的信息，里边设置了server的地址，从而让Client能够找到Server，示例如下
[libdefaults]
default_realm = ATHENA.MIT.EDU
[realms]
ATHENA.MIT.EDU = {
kdc = kerberos.mit.edu
admin_server = kerberos.mit.edu
}
/var/kerberos/krb5kdc/kdc.conf中主要保存了server端的配置，包括server端口，数据库存放地址，票据有效期等，示例如下：
[kdcdefaults]
kdc_ports = 88,750
[realms]
ATHENA.MIT.EDU = {
kadmind_port = 749
max_life = 12h 0m 0s
max_renewable_life = 7d 0h 0m 0s
database_name = /var/krb5kdc/principal
acl_file = /var/krb5kdc/kadm5.acl
}
2， 名词解释
KDC：即Key Distribution Center, 密钥分发中心，负责颁发凭证
Kinit：Kerberos认证命令，可以使用密码或者Keytab。
Realm：Kerberos的一个管理域，同一个域中的所有实体共享同一个数据库
Principal：Kerberos主体，即我们通常所说的Kerberos账号(name@realm) ，可以为某个服务或者某个用户所使用
Keytab：以文件的形式呈现，存储了一个或多个Principal的长期的key，用途和密码类似，用于kerberos认证登录；其存在的意义在于让用户不需要明文的存储密码，和程序交互时不需要人为交互来输入密码。
3，简单使用
在安装好Kerberos和对Kerberos有一个简单的认识之后，你就可以试用一下了，最基本的命令就是kinit，是Client用来从KDC获取票据的，示例如下：
a，使用密码： kinit name@realm 然后根据提示输入密码即可
b，使用keytab： kinit -kt /path/to/keytab name@realm
kinit成功之后你获取的票据就会缓存到本地，可以用klist查看，实例如下：
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: h_test@XIAOMI.HADOOP
Valid starting Expires Service principal
03/13/16 17:08:42 03/14/16 17:08:42 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
renew until 03/11/26 17:08:42
从中也可以看到过期时间。
如果你要销毁当前获取的票据，用kdestroy即可。
当然在kinit之前，server端首先要有你的账号，这就需要管理员使用addprinc命令在Kerberos数据库中添加，更多详情请戳这里。
4，Kerbeos在Hadoop上应用
在Hadoop的早期版本（1.0.0）之前是没有安全认证机制的，集群默认自己的节点都是安全的，这样就导致了恶意用户的轻易入侵，修改集群数据，修改任务状态，提交任务等问题。
1.0.0后的版本加入Kerberos认证后，部署集群时需要事先将密钥放在要部署的节点上，这样集群内的节点都是通过认证的节点，只有通过认证的节点才能被正常使用，同样，通过认证的Client才能使用服务。
如果要结合上面所说的原理，那么将上面说的Server换成Hadoop集群中的Namenode，Datanode即可。
四，Kerberos账号管理
Kerberos本身的数据库中不能查看密码的，也没有保存账号使用人等信息，所有的信息都需要以命令行的形式获取，管理起来极不方便，因此我们就开发了一套基于Django web框架的Kerberos账号管理系统（Kerberos Account Management System，简称KAS），以此来提高管理员的工作效率，让管理员更有效、更有条理的管理Kerberos账号，KAS的基本组件如下：
权限管理模块：设定了用户，用户组等角色；admin，read等权限类型；并将Kerberos账号视作一种资源类型；这样就有了某个角色，拥有某种资源的某种权限的一种通用架构，所以，这个模块适用于各种资源管理系统。
工具管理模块：里边包含了KAS需要的各种工具，例如KAS和Kerberos server交互的工具，邮件发送工具等。
账号申请模块：为了减少沟通成本，我们设计了用户提交申请，管理员审批的账户申请流程，在审批阶段用户和管理员可以对申请账号做出评论，并可以视情况对申请账号做出重新编辑，撤销申请等操作，一旦有人提交了申请，做出了评论，或者其他操作系统会发邮件通知管理员和用户，以便减少账号申请时间。
账号管理模块：对于通过审批的账号，用户可以查看密码，导出账号keytab，查看账号owner等，对账号有admin权限的账户还可以将账号授权给他人使用，以此来减小管理员的工作量。
API模块：由于有一些特殊人员因为工作的需要，希望查看或者使用owner为其他人的账号，所以我们设计了API模块；当有人需要使用API接口时，需要向管理员申请将自己设为超级用户，同时超级用户需要维护一个自己的机器列表，只有在此机器列表包含的Host上才能使用API接口，此外超级用户还需要到系统中查看自己的auth_token，用于在使用API接口时做校验。
Replicate模块：Web端的增删改查等操作只是修改了MySQL数据库，此时我们需要Replicate模块将MySQL中的修改实时同步到Kerberos自己的数据库中。
机房间同步模块：当多个机房都需要使用Kerberos认证的时候，我们就需要机房间同步模块将主Server上的修改同步到其他机房中来保证数据的一致性。
备份模块：用于备份MySQL中和Kerberos Server中的数据以防数据丢失或者其他意外发生。
KAS的整体架构图如下：
服务的安全以及高可用：
对于Web Server我们采用了Keepalived vip漂移的方式来保证服务的高可用性，同一时刻只有一台Server工作，写MySQL数据库。
主Server上的Replicate模块会将MySQL中的修改实时同步到Kerberos Server中，又通过Rsync加密、增量传输的方式把主Server中的Kerberos数据库的更改同步到其他的Kerberos Server的数据库中（包括同机房的和不同机房的）。
通常一个机房中的Kerberos Server有两个，我们采用LVS或者Keepalived的方式保证服务的高可用。
Web Server，Replicate模块等的进程我们用God的守护，以确保服务在异常停止后能自动拉起。
此外，由于Kerbeos是比较基础的服务，又比较敏感，所以我们还做了端口监控，机器级别的安全加固等。
下面简单列一下KAS开发前后状态的对比，如下：
到目前为止系统已经上线近一年，期间运行状态良好，没有出现过异常宕掉的情况，很好的提升了工作效率，节约了管理员的时间。
五，后记
至此，我们讲述了一套完整的Kerberos服务使用及管理的方案，由于本人水平有限，其中难免出现一些错误，还请谅解，欢迎批评指正。