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, 28 Jan 2015 01:40:34 GMT

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

Christopher Tubbs commented on ACCUMULO-3513:
---------------------------------------------

>From Accumulo's perspective, it would just mean that we "trust" the MapReduce layer to
do the check... whether that means we choose to lock down access to the MapReduce layer, or
whatever mechanism involved in the MapReduce layer to authenticate clients is properly propagated
to Accumulo.

It doesn't prevent unwanted impersonation... it simply assigns trust to the MapReduce system
to do that. At some point, I think that's the best we can get. We cannot get direct access
to the client's credentials, so we must trust another party (in this case, the MapReduce servers).

We could require that the clients authenticate to Accumulo to generate a shared secret (really,
though, they just need to authenticate to the Authenticator implementation backing Accumulo).
This is analogous to the HDFS delegation token. The client can then give this shared secret
to the MapReduce layer to use when talking to Accumulo, to ensure that the client did actually
hand that secret to the MapReduce layer, requesting it to do work on its behalf. However,
we still need to designate the MapReduce layer as trustable in some way... because this layer
could reuse one client's credentials to perform an unauthorized task and give the results
to a different user. The whitelist mechanism gives us some assurance that we've vetted that
layer to not do those sorts of things.

If we already have to designate trust to that intermediate layer, I don't see a lot of added
value with the complexity of the delegation token mechanism to prove that it is, in fact,
doing work on behalf of a particular client.

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