[
https://issues.apache.org/jira/browse/ACCUMULO-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306151#comment-14306151
]
Christopher Tubbs commented on ACCUMULO-3513:
---------------------------------------------
bq. the YARN tasks run as the user who submitted the job
Ugh, I missed that. Sorry. Now you need to grant YARN setuid privileges.
That's... unfortunate. I suppose you also have to make assumptions about which
UID you need to use, based on the content of the delegation token, too, and I
guess there's no guarantee that this will even be the same on every node, or
match the submitter's UID. (Though, presumably, they will all be the same if
using some common login service, like AD on all the nodes.)
bq. Why does the resource manager need to authenticate with Accumulo?
It doesn't *need* to. It'd just be a good idea if it did. We have no way to
trust (vet/accredit/account for/log) the YARN layer. We don't know that it's
actually YARN.... it could be some rogue process that hasn't been vetted. We
lose the ability to mutually authenticate the service we are handing data to.
It'd be really great if we didn't have to give that up. Granted, with regular
passwords, we cannot do this either, but at least that security model and its
risks are well-understood. We can try to think of something which would make
this more secure than that.
bq. I'm not sure I understand what you mean here: No user code is being run
with YARN's credentials.
Yes, I know this is how it works. I'm simply describing the competing goal.
YARN is implemented this way to make it impossible for tasks to use the node's
own credentials, but that's precisely what would be useful for Accumulo so it
knew that the requester was the trusted YARN layer.
> 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)
