Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Wed, 28 Jan 2015 02:56:34 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12769460.1421964371000.190941.1422413794653@Atlassian.JIRA>
In-Reply-To: <JIRA.12769460.1421964371000@Atlassian.JIRA>
References: <JIRA.12769460.1421964371000@Atlassian.JIRA>
 <JIRA.12769460.1421964371408@arcas>
Subject: [jira] [Commented] (ACCUMULO-3513) Ensure MapReduce functionality
 with Kerberos enabled
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

bq. Without the whitelist, and only the delegation token, all we can do is trust that the MapReduce layer authenticated the client at some point, for some purpose. With the whitelist, we can trust that we've vetted the MapReduce layer to function properly. If we already have that degree of trust, the delegation token is kinda moot.

I'm not sure you understand how the delegation token would work. The client would need to communicate with an Accumulo process to obtain some shared secret between Accumulo and that client. So, in addition to knowing that YARN is vetting that the "real" user is running the tasks on YARN, we know that the "real" user is going to be communicating with us using the shared secret we agreed upon.

When YARN actually runs the tasks for us, as that unix user acct tied to the client, that yarn task will have the shared secret (that we trust YARN to keep safe when it leaves the client's possession and go into the cluster), we let Accumulo RPCs happen using the shared secret instead of the KRB credentials. The YARN task isn't connecting to Accumulo with it's principals because, again, it's not running as a {{yarn}} user, but the "real" user".

So, no. I say again that the delegation token is not moot :)

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