[
https://issues.apache.org/jira/browse/SLIDER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140808#comment-14140808
]
Steve Loughran commented on SLIDER-446:
---------------------------------------
This slider principal & keytab. They're really per-user, aren't they? your long
lived cluster != my long-lived cluster.
I need to set up the registry with right permissions too; [email protected]
must have write to {{/users/stevel}} whil e {{[email protected]}} must not
> 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)
