accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3513) Ensure MapReduce functionality with Kerberos enabled
Date Wed, 04 Feb 2015 22:48:34 GMT

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

Mime
View raw message