[
https://issues.apache.org/jira/browse/ACCUMULO-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305989#comment-14305989
]
Christopher Tubbs commented on ACCUMULO-3513:
---------------------------------------------
{quote}YARN processes have kerberos principals and credentials, but the tasks
they spawn do not.{quote}
Oh. Interesting. So, the YARN process can securely authenticate itself with the
job controller (NodeManager? I'm not sure terminology here) before a job is
submitted, but the task doesn't have access to that. How do they prevent the
tasks from getting access to the parent process' Kerberos keytab? How are these
tasks sandboxed? Could our Input/OutputFormat be configured to access this
keytab? I guess you might not want to do that if you don't trust the job which
was submitted, but I'm not sure how we (Accumulo services) can trust that the
request is coming from a trusted YARN service, and not some other party which
maliciously gained access to a client's delegation token.
{quote}This would require us have clients hold onto N delegation tokens
though.{quote}
No, there'd still only be one delegation token in play, but whoever generated
it might change. I'm suggesting instead of a global, fixed "leader" involving
coordination, a random "leader" is selected for each delegation token.
{quote}You need the coordination to roll new secret keys. Using the same secret
key for months (assuming average uptime of a cluster) is just asking for
attacks.{quote}
That's not what I was suggesting. I was suggesting eliminating the need to
coordinate between servers by making one server responsible for each token
(corresponding to a temporary key stored within that tserver).
{quote}Code will speak better than I can:...{quote}
Cool. Will take a look.
> Ensure MapReduce functionality with Kerberos enabled
> ----------------------------------------------------
>
> Key: ACCUMULO-3513
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3513
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Blocker
> Fix For: 1.7.0
>
> Attachments: ACCUMULO-3513-design.pdf
>
>
> I talked to [~devaraj] today about MapReduce support running on secure Hadoop
> to help get a picture about what extra might be needed to make this work.
> Generally, in Hadoop and HBase, the client must have valid credentials to
> submit a job, then the notion of delegation tokens is used by for further
> communication since the servers do not have access to the client's sensitive
> information. A centralized service manages creation of a delegation token
> which is a record which contains certain information (such as the submitting
> user name) necessary to securely identify the holder of the delegation token.
> The general idea is that we would need to build support into the master to
> manage delegation tokens to node managers to acquire and use to run jobs.
> Hadoop and HBase both contain code which implements this general idea, but we
> will need to apply them Accumulo and verify that it is M/R jobs still work on
> a kerberized environment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
