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 19:20:35 GMT

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

Mime
View raw message