Kerberos

在上篇讲到了，HDFS Delegation Token 问题的解决方法是 Spark-Submit 方式可以进行解决，经过了一段时间的反思和查看 Livy 和 Spark-Submit 两者日志之后，有了一点新发现，并且测试认证了，该方式是可行的，那么是怎么实现的呢？上篇传输门：地址上文我有提到 livy spengo 是通过代理的方式实现 Kerberos 的认证的，当使用类似于 Spark-Submit 方式 添加对应的 spark.yarn.keytab 和 spark.yarn.principal Livy 日志中会存在 –proxy-user or –principal 的错误信息，在比对了两种方式的认证日志，发现 Livy 代理方式在 realUser 是 Livy，而 Spark-Submit 方式则为空。因而联想到了，可能 Livy 代理模式导致这两种结果的不同。在查看 Livy 配置资料之后, livy.impersonation.enabled 配置有关，尝试将该配置项设为 false 。在通过上篇中的测试方法，将 dfs.namenode.delegation.key.update-interval，dfs.namenode.delegation.token.max-lifetime，dfs.namenode.delegation.token.renew-interval 进行相应的调小，帮助快速论证结果。需要注意的一点，在测试过程中，Spark 应用是需要发消息，也就是数据，不能仅仅是运行，因为如果不发消息，其实应用是没有在正常运行的，也就不会出现过期的问题了。实验的结果是该种方式 Livy 是可以解决 HDFS Delegation Token 失效问题的。如果只是使用 Livy 方式提交，上篇中的 HDFS 的配置 hadoop.proxyuser.yarn.hosts=* 是不需要进行相应的修改的，在 HDP 环境中该配置是一个具体的 host 地址。以上

由于我们团队是最近上的 Kerberos ，免不了会出现一些问题，现阶段还处于踩坑阶段。希望通过我们的填坑的经历，帮助到同样身处坑内的伙伴。我们使用的 Hortonworks-HDP 环境。HDFS Delegation Token 问题被发现于一个 Long Running 的 Spark 应用。由于发布周期原因，部分应用超过了 7 天的有效期时间，突然在同一时间，爆发出来。当时觉得很诡异，在查看日志之后，还没有往有效时间方面考虑，还以为是环境问题。遇到的错误信息如下：org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.token.SecretManager$InvalidToken): token (token for dmp: HDFS_DELEGATION_TOKEN owner=dmp, renewer=yarn, realUser=livy/test-dmp7.example.org@TESTDIP.ORG, issueDate=1547640792209, maxDate=1547641392209, sequenceNumber=4439, masterKeyId=172) is expired, current time: 2019-01-16 20:21:06,530+0800 expected renewal time: 2019-01-16 20:16:18,863+0800Caused by: org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.token.SecretManager$InvalidToken): token (token for dmp: HDFS_DELEGATION_TOKEN owner=dmp, renewer=yarn, realUser=livy/test-dmp7.example.org@TESTDIP.ORG, issueDate=1547640792209, maxDate=1547641392209, sequenceNumber=4439, masterKeyId=172) is expired, current time: 2019-01-16 20:21:06,530+0800 expected renewal time: 2019-01-16 20:16:18,863+0800无巧不成书，另一个团队在使用我们团队的 HBASE ，因而，他们需要使用 Kerberos 认证，在他们的应用上出现了，如下图错误：出现的场景，简单描述一下，不是这篇的重点。应用为 Spring Boot 项目，使用 ZK 方式进行认证，在运行时间大于 1 天 之后就会出现该错误。后来问题定位到 Kerberos 中的认证有效期问题。缘该问题的出现，联想到是否 HDFS Delegation Token 也是 Kerberos 导致的问题呢。故而团队小伙伴进行了论证，先是修改 KDC 有效时间，为了快速论证，将 ticket_lifetime 和 renew_lifetime 都进行了调小处理，使用 Livy Spengo 方式进行提交 Spark 应用，发现在调小之后的 renew_lifetime 时间范围内，没有出现 HDFS Delegation Token 错误信息，结果与预想的出现了偏差，结合线上的问题现象为 7 天过期结果，猜测是否存在另一种配置项，在影响着。在一篇 hdfs delegation token 过期问题分析 文章中看到了另一种可能性，Hadoop 自身存在一种轻量级认证方式。故而，在 Hadoop 官网 hdfs-default 找到了如下的配置项：配置项默认值说明dfs.namenode.delegation.key.update-interval86400000The update interval for master key for delegation tokens in the namenode in milliseconds.dfs.namenode.delegation.token.max-lifetime604800000The maximum lifetime in milliseconds for which a delegation token is valid.dfs.namenode.delegation.token.renew-interval86400000The renewal interval for delegation token in milliseconds.从默认值看，似乎可以解释现象，一切通过实践出真知。也是通过对这三个参数进行相应的调小操作，结果现象跟猜测的是一致的。所以有理由相信，通过调大上面的这三个参数就可以解决问题。但是，出于安全的考虑，还是希望有不同的解决方案。如果能在过期的时候，主动进行续租或者重新认证，那应该是最好的解决方法。在 Spark 官网 security 下有一段话是这样的写的：Long-Running ApplicationsLong-running applications may run into issues if their run time exceeds the maximum delegation token lifetime configured in services it needs to access.Spark supports automatically creating new tokens for these applications when running in YARN mode. Kerberos credentials need to be provided to the Spark application via the spark-submit command, using the –principal and –keytab parameters.The provided keytab will be copied over to the machine running the Application Master via the Hadoop Distributed Cache. For this reason, it’s strongly recommended that both YARN and HDFS be secured with encryption, at least.The Kerberos login will be periodically renewed using the provided credentials, and new delegation tokens for supported will be created.–principal, –keytab 这两个参数，在上文中提到，我们团队使用的是 Livy 方式提交应用，而这里是 spark-submit ，Anyway，先进行测试再说，跟官网文档进行实践 spark-submit 方式进行。例子：./bin/spark-submit \ –class <main-class> \ –master <master-url> \ –deploy-mode <deploy-mode> \ –conf <key>=<value> \ –principal <value> \ –keytab <value> \ <application-jar> \ [application-arguments]还是重重的受到打击，依旧无法自动续租。在此之后，Google 一番，发现存在 hdfs delegation token 和 Livy 无法正常续租问题大量存在：HDFS-5322LIVY-44Hadoop安全实践SPARK-14743park jobs failed with delegation token renewal error也尝试了这些文中所说的方式方法，比如：–conf spark.hadoop.fs.hdfs.impl.disable.cache=true 之类的。尝试了 livy 和 spark-submit 都失败告终。在发现 Spark踩坑之Streaming在Kerberos的hadoop中renew失败 该文，里面有这样的配置：<property> <name>yarn.resourcemanager.proxy-user-privileges.enabled</name> <value>true</value></property># xml core-site.xml<property> <name>hadoop.proxyuser.yarn.hosts</name> <value></value></property><property> <name>hadoop.proxyuser.yarn.groups</name> <value></value></property>在与自己的环境的配置做对比之后，发现唯一不同的地方是 hadoop.proxyuser.yarn.hosts 的值，我们的配置是 host 地址，已经是死马当活马医的心态，进行尝试，发现在 spark-submit 方式成功了，但 Livy 方式还是以失败告终。但似乎更加相信 Livy 是可以实现的。尝试使用在 livy 中添加 –keytab 和 –principal 方式提交，在日志中会有 –proxy-user or –principal 的错误信息。livy spengo 是一种代理的方式进行提交。如若添加 –principal 是不支持的。对应的是 spark.yarn.keytab 和 spark.yarn.principal。同时，也检查了 hadoop.proxyuser.livy.hosts 配置是*。貌似问题是 Livy 方式无法将keytab 信息透传到 Yarn 中。希望有碰到相关问题的伙伴，能进行留言进行相应的讨论，以帮助更多的人。 ...