記一次HDFS Delegation Token失效問題

由於我們團隊是最近上的 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+0800
Caused 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 找到了如下的配置項：

從預設值看，似乎可以解釋現象，一切透過實踐出真知。也是透過對這三個引數進行相應的調小操作，結果現象跟猜測的是一致的。所以有理由相信，透過調大上面的這三個引數就可以解決問題。但是，出於安全的考慮，還是希望有不同的解決方案。

如果能在過期的時候，主動進行續租或者重新認證，那應該是最好的解決方法。在 Spark 官網 security 下有一段話是這樣的寫的：

Long-Running Applications

Long-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-5322
• LIVY-44
• Hadoop安全實踐
• SPARK-14743
• park 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 中。希望有碰到相關問題的夥伴，能進行留言進行相應的討論，以幫助更多的人。

後續傳送門：地址