自动生成Kerberos的keytab文件

隶属于文雀备章系列： 大数据安全实战 https://www.jianshu.com/p/76627fd8399c

根据服务请求，自动生成keytab文件渣岁桥

功能：

1、生成principle

2、生成keytab文件

2、接口返回principle 和 keytab

思路：

报错：在kdc上没有创如猛建当前principal

在keberos Authentication中，Kerberos有三个主体：Client、Server和KDC。

为了便于理解，这里引入两个关键的概念：

以上就是Kinit 做的事情，以后访问各个Service就用这个加密的TGT就可以了。

真正运行访问Service的程序时，进行一下步骤：

Client向Server发送的数据包被某个恶意网络监听者截获，该监听者随后将数据包座位自己的Credential冒充该Client对Server进行访问，在这种情况下，依然可以很顺利地获得Server的成功认证。为了解决这个问题，Client在Authenticator中会加入一个当前时间的Timestamp。在Server对Authenticator中的Client Info和Session Ticket中的Client Info进行比较之前，会先提取Authenticator中的Timestamp，并同当前的时间进行比较，如果他们之间的偏差超出一个可以接受的时间范围（一般是5mins），Server会直接拒绝凳迟谈该Client的请求。

Kerberos一个重要的优势在于它能够提供双向认证：不但Server可以对Client 进行认证，Client也能对Server进行认证。具体过程是这样的，如果Client需要对他访问的Server进行认证，会在它向Server发送的Credential中设置一个是否需要认证的Flag。Server在对Client认证成功之后，会把Authenticator中的Timestamp提出出来，通过Session Key进行加密，当Client接收到并使用Session Key进行解密之后，如果确认Timestamp和原来的完全一致，那么他可以认定Server正式他试图访问的Server。

那么为什么Server不直接把通过Session Key进行加密的Authenticator原样发送给Client，而要把Timestamp提取出来加密发送给Client呢？原因在于防止恶意的监听者通过获取的Client发送的Authenticator冒充Server获得Client的认证。

delegation token其实就是hadoop里一种轻量级认证方法，作为kerberos认证的一种补充。理论上只使用kerberos来认证是足够了，为什么hadoop还旦腔要自己开发一套使用delegation token的认证方式呢？这是因为如果在一个很大的分布式系统当中，如果每个节点访问某个服务的时候都使用kerberos来作为认证方式，那么势必对KDC造成很大的压力，KDC就会成为一个系统的瓶颈。

kerberos认证需三方参与，client， kdc， server三方协作完成认证。

Delegation token的认证只需要两方参与，client和server。而且可以传递给其它服务使用，这也是它叫delegation token的原因。比如在client端获取到hdfs delegation token后，可以分发到各个executor，各个task就可以不通过kerberos直接使用token访问hdfs

delegation token有过期时间，一般 token每24小时刷新一次，否则就失效，且token寿命为7天，七天后该token就不能再使用。

对于spark streaming, storm等这种长时运枣碰行应用来说，不得不面临一个问题：token存在最大生命周期。当token达到其最大生命周期的时候，所有的工作节点（比如spark streaming的executor）中使用的token都会失效，此时在使用该token去访问hdfs就会被namenode拒绝，导致应用异常退出。

一种解决思路是将keytab文件分发给Am及每个container，让am和container去访问kdc来认证，但这种方式会给KDC造成很大的访问压力，导致KDC会误认为自己遭受了DDos攻击，从而影响程序性能。

另一种解决思路是先由client把keytab文件放到hdfs上。然后在Am中使用keytab登录，并申请delegation token。Am在启动worker的时候把该token分发给相应的容器。当token快要过期的时候，Am重新登录一次，并重新获取delegation token，并告知所有的worker使用更新后的token访问服务。

spark使用的就是第二种解决思路，spark 为了解决DT失效问题，加了两个参数"--keytab"和"--principal"，分别指定用于kerberos登录的keytab文件和principal，通过在AM中login然后定期更新token实现了任务七天不挂

一、windows上使用kerberos进入访问集群（ https://blog.csdn.net/hadoop_sc/article/details/84108404 ）

1.步骤：

（1）在windows上安装了kerberos的客户端后，

（2）将KDC Server服务器上/ect/krb5.conf文件中的部分内容，拷贝到krb5.ini文件，然后重启kerberos客户端

（3）在Window下使用kinit测试

1）KDC Server上通过admin创建一个用户：

sudo kadmin.local

创建用户：addprinc znn@HADOOP. COM

设置密码：123456

创建成功

  2）启动Windows上的kerberos客户端，get ticket，输入新创建的用户

3）销毁获取到的Ticket

选中列表中需要销毁的Ticket，点击Destroy Ticket，客户端没有principal

4）命令行下初始化，在cmd中安装kerberos客户端的目录下，执行kinit znn@HADOOP.COM，

刷新一下客户端，就可以看到principal了，见下图

5）命令行下kdestroy

（4）使用Keytab文件登录Kerberos

1）在KDC Server创建一个keytab文件，使用上一步创建的 znn@HADOOP.C OM

sudo kadmin.local

创建keytab：xst -norandkey -k znn123.keytab znn@HADOOP.C OM

注意：创建的znn123.keytab，默认放置在/etc/security/keytabs

在生成keytab文件时需要加参数”-norandkey”否则会导致，直接使用kinit test@CLOUDERA.com初始化时会提示密码错误。

2)测试znn123.keytab文件

注意：在非root用户下需要将生成的keytab文件，权限设置到644以上，否则会初始化失败或者使用sudo权限初始化

3）将生成的test.keytab文件拷贝到Windows Server上，在CMD命令行进行初始化

（5）在火狐上访问集群的hdfs路径

1）直接访问hdfs的50070页面时，会d出kerberos的客户端冲配提示页面（前提是打开kerberos的客户端）

由于此时未将hdfs的ticket初始化所以不能正常访问，提示输入principal和密码

2）在集群的57服务器上找到hdfs的keytab文件hdfs.headless.keytab

3）在服务器上测试该keytab文件有效

kadmin.local

listprincs hdfs*

注意：可以使用listprincs列出的hdfs身份进行初始化

4）将hdfs.keytab文件拷贝到Windows机器上，通过CMD命令进行初始化

5）再次通过FireFox浏览器访问HDFS服务，正常访问

2.在此过程中遇到的问题：

（1）get ticket时，提示：Kerberos 5:Cannot find KDC for requested realm(error-1765328230)

原因是：在旧的集群10.247.33.57上创建的用户，但是本地的krb5.ini文件中配置的是新集群散神指10.247.32.247的/etc/瞎岩krb5.conf文件中的内容，所以提示该错误

解决办法：

修改本地的krb5.ini文件，复制老集群的文件

---