# kerberos
## 概述
### kerberos的工作围绕着票据展开,票据类似于人的驾驶证,驾驶证标识了人的信息以及可以驾驶的车俩等级
### 只有经过认证的客户端才能访问集群的服务
### 简单说明:client去票据服务大厅获取身份ticket(TGT),如果client想要获取具体服务就要拿着服务大厅颁发的身份ticket(TGT)去获取某项服务的ticket(SGT),然后拿着SGT去和某项服务的service进行享受服务(通信交互)。
## 几个概念
### 证明身份的问题
- 共享密钥
- Client与KDC, KDC与Service 在协议工作前已经有了各自的共享密钥(CK 、SK)
- sessionKey
- sessionkey是用于service和client之间的身份认证。由KDC生成。
- 如果一个秘密(secret)仅仅有认证方和被认证方知道
- 认证过程
- 被认证方向server提供以明文形式表示的Client标识和使用secret加密的client标识的密文
- 由于secret仅仅存在于client和server之间,所以server能够解密client发送过来的密文,server将解密的密文和发送过来的明文进行比较,如果完全一样就证明了client的身份
### KDC:kerberos的服务端程序。密钥分发中心,负责管理发放票据记录授权
### realm(域):kerberos管理领域的标识
### principal(实体):client需要访问服务的用户(principal)。当每添加一个用户或者服务的时候都需要向KDC添加一条principal,principal的形式为 主名称/实例名@领域名
### service:集成kerberos的服务,如HDFS/YARN/HBASE等
### 主名称:主名称可以是用户名或者服务名,还可以是单词host,表示是用于提供各种网络服务(如ftp,rcp,rlogin)的主体。
### 实例名:实例名简单理解为主机名
### TGT: client 向KDC发送身份信息(明文和CK加密的信息),KDC用CK解密认证,然后KDC从TGS(ticket Granting Service)得到TGT并用CK加密形成加密TGT回复给Client ,只有client才能用CK进行解密
### SGT: client向KDC发送TGT获取请求其他Service的Ticket。SGT包含:sessionKey和用户信息,并且用SK进行加密(client无法解密)。和SGT一起返回的信息中还有用CK加密的sessionkey信息(该消息client用CK可以解密获得sessionkey)
### SGT转发: client将SGT和 用sessionkey加密的client信息进行加密的Authenticator信息,发送给service
### service认证:service用SK将SGT解密,从而获得sessionkey和用户信息,然后用sessionkey可以解密Authenticator信息,获得用户信息,然后两部分信息进行对比,从而实现认证
## kerberos协议过程
### 第一阶段
- 客户机初始验证(KDC对client身份认证)
- KDC对client身份认证
- 当客户端用户(principal)访问一个集成kerberos的服务之前,需要先通过KDC的身份认证
- 登录(或使用kinit)时,客户机请求允许其获取服务票证的TGT。
- KGC检查数据库,发送TGT
- 如身份认证通过则客户端会拿到一个TGT(ticket granting ticket),后续就可以拿到该TGT去访问集成了kerberos的服务
- 客户机使用口令解密TGT,进而提供标识:现在可以使用TGT获取其他票证。
### 第二阶段
- 获取对服务的访问(service对client身份认证)
- 当用户拿到TGT后,就可以继续访问service服务
- 客户机请求服务器票证:向KDC发送TGT作为标识的证明。
- KDC向客户机发送服务器票证(SGT)
- 他会使用TGT以及需要访问的服务名称(如HDFS)去KDC获取SGT(service granting ticket)
- 1. Client将之前获得TGT和要请求的服务信息(服务名等)发送给KDC
2. KDC中的Ticket Granting Service将为Client和Service之间生成一个Session Key用于Service对Client的身份鉴别 3. 然后KDC将这个Session Key和用户名,用户地址(IP),服务名,有效期, 时间戳一起包装成一个Ticket(这些信息最终用于Service对Client的身份鉴别)发送给Service, 不过Kerberos协议并没有直接将Ticket发送给Service ,而是将SGT发送给client 4. 由于SGT是要给service的,不能让client看到,所以KDC用协议开始前KDC和service之间的密钥将ticket加密形成SGT转发给client,同时为了让client和service之间共享那个秘密(KDC在第一步为他们创建的session key),KDC用client与它之间的密钥将session key加密随加密的Ticket(SGT)一起返回给client 5。client将收到的SGT转发给service 由于Client不知道KDC与Service之间的密钥,所以他无法篡改信息,同时将client接收到sessionkey解密出来,然后将自己的用户名和用户地址打包成Authenticator用sessionkey加密也发送给Service
6. service接收到SGT后然后利用它和KDC之间的秘密将SGT解密出来,从而获取sessionkey和用户信息,然后用sessionkey将Authenticator解密出来从而获得用户信息,将两部分用户信息进行比较从而验证client的身份
- 客户机向服务器发送票证(SGT)
- 然后使用SGT去访问Service,service会利用相关信息对client进行身份认证,认证通过后就可以正常访问service服务
- 服务器允许客户机访问
*XMind: ZEN - Trial Version*