其他分享
首页 > 其他分享> > 【Kerberos】快速入门与使用笔记

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

作者：互联网

前略：在印象笔记里躺了一段时间了，凑巧翻到分享出来给被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