accumulo-notifications mailing list archives

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

    [ https://issues.apache.org/jira/browse/ACCUMULO-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306004#comment-14306004
] 

Josh Elser commented on ACCUMULO-3513:
--------------------------------------

bq. 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.

ResourceManager, but yes, I think you have the point. 

bq. How do they prevent the tasks from getting access to the parent process' Kerberos keytab?

So, it's an entirely new process, so there's no shared memory. Keytabs on disk should be protected
by the filesystem.

bq. How are these tasks sandboxed?

A little C program is executed by the nodemanager which does your normal fork(), drops permissions
on the child process, and runs the actual yarn task.

bq. Could our Input/OutputFormat be configured to access this keytab?

No, for the above reason -- we cannot read it. If it was generally open, anyone could impersonate
the yarn processes.

bq. 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.

Like any password, it's expected that the delegation token is protected from prying eyes.
The time-limit on the validity of the delegation token helps mitigate some concern, but that's
a very small mitigation. We ultimately need to rely on YARN (which it is doing) to keep the
delegation token safe from prying eyes from when it leaves the client's possession and makes
it way to the actual yarn task.

> 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