[
https://issues.apache.org/jira/browse/SLIDER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140799#comment-14140799
]
Jonathan Maron commented on SLIDER-446:
---------------------------------------
I'm not certain that mapreduce cares much about token renewal given that most
jobs are short lived. The renewal period, by default, is 24 hours. But
mapreduce does have its own principals/keytabs for security identity management.
> delegation token renewer identity may require definition of 'slider' user and
> principal
> ---------------------------------------------------------------------------------------
>
> Key: SLIDER-446
> URL: https://issues.apache.org/jira/browse/SLIDER-446
> Project: Slider
> Issue Type: Bug
> Components: appmaster, security
> Affects Versions: Slider 0.50
> Reporter: Jonathan Maron
> Assignee: Jonathan Maron
>
> Currently the HDFS delegation token renewal framework needs to establish a
> user/subject using kerberos (not tokens) in order to perform the token
> renewal or replacement operations. Given that it was HDFS, the current
> implementation leverages the namenode principal as the renewing identity.
> However, this approach does not work if the node on which the AM is running
> doesn't actually have access to the namenode keytab. So, as I see it, there
> are a number of alternatives:
> 1) Looks for a datanode keytab if the namenode keytab is not available and
> use the DN service principal - probably not the best choice since, once
> again, there's no guarantee that a DN is running on the NM host.
> 2) Use the NM principal/keytab - this may be appropriate. Are there any
> permission issues in leveraging a yarn principal with HDFS?
> 3) Create a slider-specific service principal and keytab - this would seem
> to be appropriate given the precedent set in Hadoop (most secure applications
> appear to manage their own set of principals).
> 4) Others?
> Given that this subject may engender multiple opinions, I could use option 2
> as an interim (and possibly final) solution?
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
