[ https://issues.apache.org/jira/browse/HDFS-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14186481#comment-14186481 ]
bc Wong commented on HDFS-7295: ------------------------------- bq. Given the fact that in Hadoop there is no way to revoke a DT, expiration time serves as the last defense of stole tokens. Not quite true. The [mechanism|https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/token/delegation/AbstractDelegationTokenSecretManager.java#L514] is there, and even exposed in [WebHDFS|http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/WebHDFS.html#Cancel_Delegation_Token]. But I'll concede that users can't get a list of all outstanding DTs (short of using the OIV), which make revocation difficult. Let's separate the right security model from current feature limitations in HDFS. It's straightforward to build a revocation mechanism, along with some stats reporting on DT usages, plus auditing. So lack of revocation today shouldn't affect the direction we choose. The alternative, which is to put real users' keytabs on the cluster, is far worse. (Again, the use case example is a long running Spark Streaming app, which runs as a real user, not a service account.) First, a compromise on the keytab affects the user's corporate AD account. Second, normal users can't get keytabs usually. I think it's hard to for most enterprise users to accept this alternative. > Support arbitrary max expiration times for delegation token > ----------------------------------------------------------- > > Key: HDFS-7295 > URL: https://issues.apache.org/jira/browse/HDFS-7295 > Project: Hadoop HDFS > Issue Type: Improvement > Reporter: Anubhav Dhoot > Assignee: Anubhav Dhoot > > Currently the max lifetime of HDFS delegation tokens is hardcoded to 7 days. > This is a problem for different users of HDFS such as long running YARN apps. > Users should be allowed to optionally specify max lifetime for their tokens. -- This message was sent by Atlassian JIRA (v6.3.4#6332)