[
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)
