accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3513) Ensure MapReduce functionality with Kerberos enabled
Date Fri, 30 Jan 2015 23:09:35 GMT


Josh Elser commented on ACCUMULO-3513:

Thanks for taking the time to read and give feedback.

bq. Regarding DIGEST-MD5, which transport features would it support, and how do these relate
to the auth, auth-int, and auth-conf options currently available with GSSAPI?

These (the quality of protection) are at the SASL level, so I believe they work seamlessly
across the mechanism chosen.

bq. Wouldn't it be better to keep the existing GSSAPI transport, and pass the delegation tokens
on top of that layer

MapReduce *does not* have access to Kerberos tokens. This is a non-starter.

bq. Regarding the use of ZK to propagate the rolling shared secret, we'd need to be careful
about propagation delays using the watchers to update the cache. Rather than user the watchers.

That's a fair point. I'm not sure how this will look in practice (if we'll need to do something
differently). We could back these by a table which is a possibility

bq. Regarding the rolling secret: this seems like it would make client tokens vary in their
duration, and the expiration outside the control of the client user.

Yes, the maximum lifetime would be controlled by an Accumulo configuration value. This isn't
too bad to expand upon once everything else is present (e.g. clients request shorter lifetimes).

bq. Instead of relying on the master, you could make it possible for any TServer to grant
a delegation token. The resulting token could only be checked by that same TServer, but you
wouldn't have to rely on a SPOF or worry about propagation. Clients would randomly choose
a TServer to authenticate to, every time it needs a delegation token, and the delegation token
remembers who issued it.

Also true, that's why I called it out. HBase just has any node in the cluster act as the leader,
I'm not convinced that we need that level of robustness. The calls to get a delegation token
as compared to the number of authentications (1 client to N mappers). We can easily add leader
election and re-use the same service I plan to make for the master by any node in the instance.
This authentication model relies on the same secrets being shared across all nodes in the
cluster. If I'm understanding your suggestion, each server would have distinct secret keys
which would result in clients only being able to communicate to a single TabletServer (which
is a non-starter).

> Ensure MapReduce functionality with Kerberos enabled
> ----------------------------------------------------
>                 Key: ACCUMULO-3513
>                 URL:
>             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

View raw message