[
https://issues.apache.org/jira/browse/ACCUMULO-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299349#comment-14299349
]
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: 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)
