[
https://issues.apache.org/jira/browse/ACCUMULO-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299329#comment-14299329
]
Christopher Tubbs commented on ACCUMULO-3513:
---------------------------------------------
A few questions/comments about this plan:
# 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?
# Wouldn't it be better to keep the existing GSSAPI transport, and pass the
delegation tokens on top of that layer? That way, we authenticate the
middle-man, too, and not just the end user. With the DIGEST-MD5 implementation,
and skipping authentication for the middle-man, we cannot trust that the
middle-man (the NodeManager?) is managing clients delegation tokens properly
from only the RPC connection.
# 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.
# 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.
# 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.
> 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)
