云河空间

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依赖带上。


本站部分资源收集于网络,纯个人收藏,无商业用途,如有侵权请及时告知!

0
分享到:

评论

分享:

支付宝

微信