ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

【Kerberos】快速入门与使用笔记

2021-02-18 15:04:00  阅读:342  来源: 互联网

标签:krb5 入门 Kerberos 笔记 server token client 认证 KDC


前略:在印象笔记里躺了一段时间了,凑巧翻到分享出来给被Kerberos所谓“经典对话”折磨的朋友,原文对话大体没啥问题,但不是每个读者都有那个心境,而且如果学过LDAP的朋友,可能下文更好理解。

一、推导

为了尽量简化这个流程,说下简单的推导:

  1. 非对称的加密模式不适合集群模式,只能使用认证中心的方式,我们需要一个权威,此时是KDC
  2. 一切机制的目标都是保证中心的权威
  3. 中心负责保证client和server的身份正确,server信任KDC(废话),client信任KDC,server、client 互相不信任
  4. KDC保存了server密钥,server/kdc 双方知道,互相信任
  5. KDC保存了client密钥,client/kdc 双方知道,互相信任
  6. client 找KDC 要票,kdc 用client的密钥加密发了个session key 回去,同时还有client看不懂的,server信息,这部分用server的加密,server才能解开。
  7. client 解开信息,自己记下session key ,用session key 加密一段话,把这个和看不懂的扔给server
  8. server通过自己的密钥解开client的票,看到了自己的信息,于是信任client(client 解不开),同时获取到一个session key ,这个key用来解开client说的话
  9. client 收到 server的回复(这个回复是client之前用session key 加密过的那段话),信任server
  10. 10.整个过程中,client/server都不知道对方的任何秘密,唯一往来是那句回复。

二、简化的流程

下图表示简化的Kerberos流程:

 

以下表示实际获取的凭证等:

1.允许服务票证

 

 

 

Kerberos ticket具有lifetime,超过此时间则ticket就会过期,需要重新申请或renew

ticket_lifetime: tiket有效期

renew_lifetime: 通过renew操作最长可续命的时间

2.允许服务器请求票证

 

这一步的TGT又称ST(Service Ticke 、ST)

三、衍生:Delegation token.

为了减轻KDC的压力,毕竟每次服务器请求,都需要服务器票证,而服务器票证一般有效期为数分钟,在大集群高访问量情况下,每分钟上万的kdc请求也有可能。

所以Hadoop Security在做这方面优化时,引入了delegation token 的机制。通过这一步认证,我们得以在大多数时候跳过上述的步骤,在认证完成后,使用token进行client/server双方的访问,而token也引入了自己的有效期,。

Delegation Tokens作为Kerberos的一个补充,实现了一种轻量级的认证机制。Kerberos是三方认证协议,而Delegation Tokens只涉及到两方。

Delegation Tokens的认证过程如下:

  1. client通过Kerberos与Server完成认证(TGT 认证通过),并从server获取相应的Delegation Tokens。
  2. client与server之间后续的认证都是通过Delegation Tokens,而不通过Kerberos。

-->注意!此时client/server并不代指提交程序和YARN,仅是通过Kerberos认证的客户端/服务器双方。

client可以把Delegation Tokens传递给其它的服务(如:YARN),如此一来,这些服务(如:MapReduce任务)以client身份进行认证。换句话说,client可以将身份凭证"委托"给这些服务。Delegation Tokens有一个过期时间的概念,需要周期性的更新以保证其有效性。但是,它也不能无限制的更新,这由最大生命周期控制。此外,在Delegation Token过期前也被取消。

 

 

 

 

 

各种组件的token更新周期如hdfs的更新周期dfs.namenode.delegation.token.renew-interval默认为1天,hbase的token更新周期hbase.auth.key.update.interval默认为1天;调度更新的周期为如上各组件最小值的75%,

 

(一)Spark delegation token.

如上文:既然token自身存在有效期的问题,就必然有token过期的问题,对于Spark-Streaming 和 Hbase而言,这种情况变得不可接受;

spark应对这种情况时,在token即将过期时,并不指望server端(HDFS)能够继续更新token(在token自身生命周期到期以前,它一直能这么干,只是现在spark干脆连token的renew也不要了,一视同仁),因为用户程序也无法重新提交,于是只能再次认证:

 

  1. spark 通过Kerberos与 hdfs 完成认证(TGT 认证重新登录),并从 hdfs 获取相应的Delegation Tokens。
  2. spark 与 hdfs 之间后续的认证都是通过Delegation Tokens,而不通过Kerberos。

为了避免renew的周期和ticket的周期错开,spark 每次在token快过期时,都重新登录(不renew TGT),用新的TGT,生成新的token。

 

以下 摘自源码注释:

// HACK:

 

// HDFS will not issue new delegation tokens, if the Credentials object

// passed in already has tokens for that FS even if the tokens are expired (it really only

// checks if there are tokens for the service, and not if they are valid). 

// So the only real

// way to get new tokens is to make sure a different Credentials object is used each time to

// get new tokens and then the new tokens are copied over the the current user's Credentials.

// So:

// - we login as a different user and get the UGI

// - use that UGI to get the tokens (see doAs block below)

// - copy the tokens over to the current user's credentials (this will overwrite the tokens

// in the current user's Credentials object for this FS).

// The login to KDC happens each time new tokens are required, but this is rare enough to not

// have to worry about (like once every day or so). This makes this code clearer than having

// to login and then relogin every time (the HDFS API may not relogin since we don't use this

// UGI directly for HDFS communication.

 

(二)Driver 和 Executor

在yarn-client模式下,driver在yarnclient进程中启动,同样需要访问业务层及集群的相关组件如hdfs。

driver通过读取am更新在hdfs路径下的credentials文件来保证driver节点的token有效。

 

// SPARK-8851: In yarn-client mode, the AM still does the credentials refresh. The driver

// reads the credentials from HDFS, just like the executors and updates its own credentials cache.

if (conf.contains("spark.yarn.credentials.file")) {

    YarnSparkHadoopUtil.startCredentialUpdater(conf)}

 

在applicationMaster中,定期更新token,并写入文件到hdfs的相关目录,并清理旧文件以供各executor使用。

 

 

client 模式由于其特殊性,可以视作特殊的executor,毕竟 applicationMaster 在yarn上。

在yarn-cluster模式下,driver运行在applicationMaster的JVM中,其安全相关由Am同一操作

(三)UGI

代码中UGI:UserGroupInformation主要作用:

  1. 登录
  2. 启动后台线程来刷新 TGT
  3. 支持tgt的手动重刷

 

四、配置相关

领域:(Realm)是定义属于同一主 KDC 的一组系统的逻辑网络,类似于域。

 

位于:krb5.conf

 

keytab文件:

keytab文件实际只是一个密码文件,显然,修改lifetime相关设置跟密码是没有关系的,不需要去重新生成现有的keytab文件。

五、对应的命令

KDC也即服务端的命令与客户端是错开的

也即krb-admin-server\krb-kdc和krb-user 几个独立包的区别(使用apt-get时)

其中:

 服务端KDC由kadmind、krbkdc 两个命令组成

kadmind

启动AD服务,控制权限

krbkdc

启动KDC服务

 

安装见:

(中文简版)

https://www.jianshu.com/p/f84c3668272b

 

(MIT完整版)

https://web.mit.edu/kerberos/krb5-latest/doc/admin/install_kdc.html

 

服务端常用命令为:

KINIT 

获取ticket,也即第一步的TGT,后续交互由后台进程负责

KLIST

默认展示已认证的tiket

KDESTROY 

销毁所有tiket

KPASSWD

更改密码

kadmin

生成keytab

 

Linux使用任意包管理安装krb-user即可,windows在官网有安装包

 

六、不同供应商的krb5

目前krb5有许多的供应商,大体上他们实现相差无几,但是仍有部分区别,主要表现在配置上,也即与KDC交互时,使用的配置

 

以Klist命令为例,大多数厂商都实现了这一命令,在一台机子上可能找到多个klist:

 

从上往下依次是

1.windows自带klist(兼容windows自身的krb5 以及Mit 的krb5):

其路径下的ksetup读取 C:\ProgramData\MIT\Kerberos5\krb5.ini 以及 C:\windows\krb5.ini

 

2.JVM自带,调用Java代码实现:

 其路径下的kinit读取java.security.krb5.conf=/dir 设置的路径 或者 默认的  C:\windows\krb5.ini

详见Java security(JAAS)

 

3.MIT 为Windows提供的版本:

  其路径下的kinit读取 C:\ProgramData\MIT\Kerberos5\krb5.ini

4.MIT 为Linux提供的版本及其他厂商为Linux提供的版本:

    其路径下的kinit读取 /etc/krb5.conf

    其中MIT版本中的许多配置厂商实现的标准是不能用的,但是不涉及。

5.SunOS

    其路径下的kinit读取 /etc/krb5/krb5.conf

 

参考:

https://www.jianshu.com/p/ae5a3f39a9af

https://www.jianshu.com/p/7fe5351399a8

https://github.com/cloudera/spark/blob/cdh5-1.6.0_5.13.0/yarn/src/main/scala/org/apache/spark/deploy/yarn/AMDelegationTokenRenewer.scala

 

 

标签:krb5,入门,Kerberos,笔记,server,token,client,认证,KDC
来源: https://www.cnblogs.com/easy-tech/p/14411826.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有