Hadoop Security Authentication Terminology --Kerberos

最新推荐文章于 2023-07-23 08:28:43 发布

zmycoco2

最新推荐文章于 2023-07-23 08:28:43 发布

阅读量1.5k

点赞数

分类专栏：分布式数据存储 Hadoop 文章标签： Hadoop Kerberos Kinit Hadoop Authenticatio

本文链接：https://blog.csdn.net/michaelzhou224/article/details/9377933

版权

分布式数据存储 Hadoop 专栏收录该内容

63 篇文章 0 订阅

订阅专栏

Hadoop Security Authentication Terminology --Kerberos

What is kinit?

Kinit - obtain and cache Kerberos ticket-grantingticket

If you use the kinit commandto get your tickets, make sure you use the kdestroy command to destroy yourtickets before you end your login session. You should put the kdestory commandin your .logout file so that your tickets will be destroyed automatically whenyou logout.

What is Kerberos?

在Hadoop 1.0.0或者CDH3版本之前，hadoop并不存在安全认证一说。默认集群内所有的节点都是可靠的，值得信赖的。用户与HDFS或者M/R进行交互时并不需要进行验证。导致存在恶意用户伪装成真正的用户或者服务器入侵到Hadoop集群上，而已的提交作业，修改Job Tracker状态，篡改HDFS上的数据，伪装成NameNode或者TaskTracker接受任务等。尽管在版本0.16以后，HDFS增加了文件和目录的权限，但是并没有强认证的保障，这些权限只能对偶然的数据丢失起保护作用。恶意的用户可以轻易的伪装成其他用户来篡改权限，致使权限设置形同虚设，不能够对Hadoop集群起到安全保障。后来加入了Kerberos认证机制，使得集群中的节点是信赖的。Kerberos可以将认证的密钥在集群部署时事先放到可靠的节点上。集群运行时，集群内的节点使用密钥得到认证。只有被认证过节点才能正常使用。企图冒充的节点由于没有事先得到的密钥信息，无法与集群内部的节点通信。防止了恶意的使用或篡改Hadoop集群的问题，确保了集群的可靠安全。

Kerberos事先的是机器级别的安全认证，也就是前面提到的服务到服务的认证问题。事先对集群中确定的机器由管理员手动添加到kerberos数据库中，在KDC上分别产生主机与各个节点的keytab(包括了host和对应节点的名字，还有他们之间的密钥)，并将这些keytab分发到对应的节点上。通过这些keytab文件，节点可以从KDC上获得与目标节点通信的密钥，进而被目标节点所认证，提供相应的服务，防止了被冒充的可能性。

Princal(安全个体):被认证的个体，有一个名字和口令。

KDC(key distribution center)：是一个网络服务，提供ticket和临时会话密钥。

Ticket:一个记录，客户用它来向服务器证明自己的身份，包括客户标识，会话密钥，时间戳。

AS(Authentication Server)：认证服务器。

TSG(Ticket Granting Server)：许可证服务器。

Kerberos可以分为两个部分：

Client向KDC发送自己的身份信息，KDC从TicketGranting Service得到TGT(ticket-granting ticket)，并用协议开始前Client与KDC之间的密钥将TGT加密回复给Client.此时只有真正的Client才能利用它与KDC之间的密钥将加密后的TGT解密，从而获得TGT。此过程避免了Client直接向KDC发送密码，以求通过验证的不安全方式。

Client利用之前获得的TGT向KDC请求其他Service的Ticket,从而通过其他Service的身份鉴别。

Kerberos协议认证过程：

(1). Client将之前获得TGT和要请求的服务信息(服务名等)发送给KDC，KDC中的Ticket Granting Service将为Client和Service之间生成一个Session Key用于Service对Client的身份鉴别。然后KDC将这个Session Key和用户名，用户地址(IP)，服务名，有效期，时间戳一起包装成一个Ticket(这些信息最终用于Service对Client的身份鉴别)发送给Service。

(2). KDC将前面的Ticket转发给Client。由于这个Ticket是要给Service的，不能让Client看到，所以KDC用协议开始前KDC与Service之间的密钥将Ticket加密后再发送给Client。同时为了让Client和Service之间共享那个密钥，KDC用Client与它之间的密钥将SessionKey加密随加密的Ticket一起返回给Client.

(3). 为了完成Ticket的传递，Client将刚才收到的Ticket转发到Service。由于Client不知道KDC与Service之间的密钥，所以它无法修改Ticket中的信息。同时Client将收到的Session Key解密出来，然后将自己的用户名，用户地址(IP)打包成Authenticator用SessionKey加密也发送给Service。

(4). Service收到Ticket后利用它与KDC之间的密钥将Ticket中的信息解密出来，从而获得Session Key和用户名，用户地址(IP)，服务名，有效期。然后再用Session Key 将Authenticator将解密从而获得用户名，用户地址(IP)将其与之前Ticket中解密出来的用户名，用户地址(IP)做比较从而验证Client的身份。

(5). 如果Service有返回结果，将其返回给Client。