hadoop-kerberos

kerberos客户端配置

• krb5.conf配置选项参考： https://linux.die.net/man/5/krb5.conf

• 配置kerberos多用户ticket缓存名字

  1 2	#vi /etc/profile default_ccache_name = DIR:/tmp/kerberos

  说明：

• 也可以设置环境变量达到相同的效果export KRB5CCNAME=DIR:/tmp/kerberos

• kerberos客户端在任意时刻只能有一个票证可用， 所以不管如何配置都不可能达到一次配置一次认证就可以了，而是认证之后可以进行多次切换不同的认证

• 多个kerberos的krb5.conf合并

• 通常情况每个kerberos服务器有一个krb5.conf文件， 如果有多个kerberos服务器需要认证那么通常会比较麻烦，需要拷贝配置文件，所以通常情况下我们可以讲这些文件合并一个文件。通常情况下只需要合并realms 就可以了，如下：

  1 2 3 4 5 6 7 8 9

  [realms]   ILIVOO.COM = {     admin_server = sandbox-hdp.hortonworks.com     kdc = sandbox-hdp.hortonworks.com   }   EXAMPLE.COM = {     admin_server = dev1     kdc = dev1   }

• 多个keytab文件合并

  1 2 3 4

  #ktutil ktutil:  rkt /etc/security/keytabs/hdfs.keytab ktutil:  rkt /etc/security/keytabs/hbase.keytab  ktutil:  wkt /etc/krb5.keytab

kerberos客户端工具使用

• 查看keytab文件中用户

  klist -kt /etc/krb5.keytab

• 认证

  1 2	kinit -k admin/admin@ILIVOO.COM kinit -k admin/admin@EXAMPLE.COM

• 显示认证

• 显示当前认证

  klist

• 显示所以认证

  klist -A

• 切换认证

  kswitch -p admin/admin@ILIVOO.COM

• 销毁认证

• 销毁当前认证

  kdestroy

  注意销毁当前认证， 并不会自动选择一个当前认证

• 销毁所有认证

  kdestroy -A

• 更新认证

  kinit -R

kerberos服务端工具使用

说明：

1. headless keytab与没有headless的keytab的区别， 主要是headless keytab可以在任何机器上使用，而没有headless的keytab只能在特定的服务器使用， 也就是说它们是服务器绑定的， 如： headless keytab 名称是 `hdfs-ilivoo@ILIVOO.COM， 而没有headless keytab是nn/hdp1.ilivoo.com@ILIVOO.COM`

2. kerberos管理员账户： `*/admin@ILIVOO.COM(可以通过/var/kerberos/krb5kdc/kadm5.acl `指定)

• 添加Principal

  1 2	kadmin.local addprinc -randkey admin-ilivoo@ILIVOO.COM

• 导出keytab文件

  1 2 3

  cd /etc/security/keytab kadmin.local ktadd/xst -k admin.headless.keytab admin-ilivoo

  注意 : 如果keytab是随机密码的, 那么直接使用上面就可以了, 但是如果上面的keytab不是使用randkey, 那么此时必须使用 -norandkey 参数导出来才不会有错. 例如:

  1	ktadd/xst -norandkey -k admin.admin.keytab admin/admin

• 合并keytab文件

  1 2 3 4 5

  cd /etc/security/keytab ktutil rkt admin.headless.keytab rkt hdfs.headless.keytab wkt all.headless.keytab

ambari、kerberos、service、host 权限

• 对于ambari来说它是一个集群的管理着， 它有自己权限管理， 通常分为集群管理者、集群使用者、服务管理者、服务操作者、服务开发者等等。 并且它的权限用户通常也是可以和host的权限进行对应上的。如：在主机上创建了 admin 用户， 并且在ambari中创建了admin用户， 并且把admin用户配置成为集群管理者。

• kerberos主要是用来验证某个人就是自己所声称的那个人， 所以通常情况下也是和主机的用户对于的， 也就是说根据需要是否在kerberos中创建主机用户的principal。通常情况下， service使用principal验证能够访问自己的用户， 那么对应用户访问的时候就必须为自己获取票证。

• 通常来说service是为了验证的话才需要为自己开启权限验证， 并且指定只有某种用户才能访问自己， 如果其它的服务或者客户端需要访问自己， 那么就必须获得票证。并且通常来说service有自己权限验证，可以将其授权给某个用户， 也就是说想要访问service必须先证明你就是自己声称的那个人， 这样就表示通过了service的kerberos验证， 再就是service有自己的权限验证(acl)， service必须为这个用户授权之后这个用户才能访问这个服务。通常情况下服务与服务之间的kerberos验证是非常严格的， 如： DataNode想要连接到NameNode那么必须有 `nn/host@ILIVOO.COM, 而服务的使用者却比较宽泛点， 如hdfs用户想要访问集群， 那么通常只需要hdfs-ilivoo@ILIVOO.COM`， 甚至其它的用户也可以创建文件等等， 只是hdfs用户通常被指定为管理用户，其它用户需要hdfs用户为其授权。

• host权限主要是用来控制对主机的访问权限， 但是通常情况下来说host权限也与其它的权限对应上， 方便服务的开发与管理。

• 通过上面的分析， 通常情况下我们使用这些复杂的权限的时候会非常小心， 并且规划好权限对于我们的开发至关重要。如下案例：

1. 运维人员， 通常都是需要对集群进行管理， 并监控集群的状态， 通常情况可以简单分为两种运维人员， 集群管理员， 集群监测员，创建权限如下：

   集群管理员： host中创建 cluster admin 用户(cadmin), ambari中创建用户(cadmin)用户，并为其设置为集群管理员角色。

   集群监测源： host中创建 cluster view 用户(cview), ambari中创建(cview)用户， 并为其设置为集群操作员角色。

2. 开发人员， 通常对服务进行启动停止， 配置修改， 对某些服务进行访问， 通常不同的开发人员有不用的权限。如下案例：

   spark开发人员： host中创建开发用户(feng), ambari中创建(feng)，并为其设置集群服务操作员角色， 在kerberos中添加票证， 并导出keytab文件给用户。 为用户配置hdfs权限， yarn权限， spark权限，hbase权限， kafka权限， hive权限等等。

   注意： hdfs、yarn、spark、hbase、kafka、hive等为feng添加权限的时候， 通常需要先使用kinit登录到自己的权限， 再讲权限设置给feng用户。 如： hbase 为feng用户添加权限

   1 2 3

   kinit -kt /var/kerberos/keytab/hbase.headless.keytab hbase-ilivoo@ILIVOO.COM hbase shell grant  'feng', 'RWCA'   #授权feng用户有rwca权限

   当然： 现在情况有所变化， hdfs、yarn、hbase、kafka、hive等都可以使用ranger为其配置权限， 所以如果这些组件使用了ranger插件， 那么就必须使用ranger为其配置。

3. 建议能够使用hdfs自己的权限位， 就不要使用ranger来管理。

kafka安装kerberos

• 参考 https://www.cnblogs.com/dongxiao-yang/p/7131626.html

• 服务端修改基本配置

  1 2	listeners=SASL_PLAINTEXT://:6667      --修改listeners sasl.kerberos.service.name=kafka      --添加kerberos.name

• 启用kerberos后，部分kafka管理脚本需要增加额外的参数才能使用, 建立 client.properties文件

  1	security.protocol=SASL_PLAINTEXT

  新命令如下：

  1 2 3 4 5 6 7 8

  所以新命令的使用方式为 /usr/hdp/3.1.0.0-78/kafka/bin/kafka-topics.sh --create --zookeeper hdp1.ilivoo.com:2181 --replication-factor 3 --partitions 12 --topic test bin/kafka-consumer-groups.sh --bootstrap-server hdp1.ilivoo.com:6667 --list --command-config client.properties bin/kafka-console-producer.sh --broker-list hdp1.ilivoo.com:6667 --topic dxTT --producer.config client.properties 过期，需要重新申请或者renew Ticket bin/kafka-console-consumer.sh --bootstrap-server hdp1.ilivoo.com:6667 --topic dxTT --consumer.config client.properties --from-beginning

kerberos遇到的问题

• kinit -R 无法续约，这是因为kerberos的每个principal都可以指定超过此时间则ticket就会过期，需要重新申请或者renew有效时间和刷新时间， 默认添加principal的时候并没有指定它的刷新时间和有效时间，所以就使用了服务器默认配置的时间

  kerberos Server上的/var/kerberos/krb5kdbc/kdc.conf中的max_life kadmin.local

  1 2 3 4

  modprinc -maxlife "1 week" feng@ILIVOO.COM modprinc -maxrenewlife "1 week" feng@ILIVOO.COM modprinc -maxlife "1 week" krbtgt/ILIVOO.COM@ILIVOO.COM modprinc -maxrenewlife "1 week" krbtgt/ILIVOO.COM@ILIVOO.COM

  注意：krbtgt表示服务端的tgt必须设置， 设置完成需要重新kinit

• kerberos 的票据的生命周期由lifetime和renewlifetime决定， 当生命周期超过lifetime则ticket就会过期，需要重新申请或者renew，如果重新申请非常容易理解， 直接重新申请就可以了。如果需要renew则首先要开启renew功能， 由上一个问题解决。通常情况下来说，renewlifetime会大于lifetime，如：lifetime=2d，renewlifetime=7d。而这两个时间由五个基本的时间决定：

  注意：上面五个生命周期依次往上逐渐取最小

• 最基本由kerberos Server上的/var/kerberos/krb5kdbc/kdc.conf中的max_life 和 max_renewable_life决定

  1 2 3 4 5 6

  [realms]  ILIVOO.COM = {   max_life = 2d   max_renewable_life = 7d   ...  }

• 内置principal krbtgt的maxmum ticket life 和 renew life,可在kadmin命令下执行getprinc命令查看

• 使用的principal的maximum tiket life 和 renew life，可在kadmin命令下用getprinc命令查看

• 再就是kerberos client上/etc/krb5.conf的ticket_lifetime 和 renew_lifetime

  1 2 3 4

  [libdefaults]   ticket_lifetime = 2d   renew_lifetime = 7d   ...

• kinit 参数后面指定的时间, 如： kinit -l 2d -r 7d my_principal

• kerberos spark集群连接hbase、kafka， 由于spark以及处理了kerberos认证问题，在spark的Driver启动的时候spark获取kerberos认证， 并将认证打包成代理Token存放在HDFS上， 当启动Executor的时候会带上这个Token用于Executor上的验证。当Token快要失效的时候Spark Driver会再次去刷新认证， 并讲认证信息告诉Executor，从而保证整个过程中长时间运行。

  注意：hbase的classpath是一个麻烦的事情， 因为通常情况下如果简单指定hbase-client会导致hbase 在Executor中没有认证的现象，所以必须讲hbase-server依赖带上。