[jira] [Commented] (ACCUMULO-3513) Ensure MapReduce functionality with Kerberos enabled

["Christopher Tubbs (JIRA)" <ji...@apache.org>]

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

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

NOTE: DIGEST-MD5 is ill-advised, due to problems: http://tools.ietf.org/html/rfc6331

That's not to say that it couldn't be useful, if deployed properly. I'm just reluctant to rely on deprecated security modes, because it could give a false sense of confidence in the security being implemented.

{quote}MapReduce does not have access to Kerberos tokens. This is a non-starter.{quote}

The individual MapReduce nodes do not have Kerberos principals at all? How do they authenticate to the job controller?

{quote}... We can easily add leader election...{quote}

My point was that we don't need to do leader election. Rather, each TServer is just as good as any other to authenticate users, so rather than elect a single leader, you can simply allow any of them to issue tokens (concurrently). The only restriction is that to validate that token, you have to talk to the TServer which issued it... but that's better than always talking to a single leader or the master.

{quote}... This authentication model relies on the same secrets being shared across all nodes in the cluster. ...{quote}

If you use a single shared key, you *really* don't need leader election (because they all have the secret and perform the same function). However, I was actually thinking that each TServer would have a temporary key with which to generate delegation tokens. So long as that TServer hadn't crashed, it could validate any delegation tokens created from it.

I'm very curious precisely how you are generating these delegation tokens, though. I could be on a completely separate page regarding that and your suggestion for leader elections.

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