accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3513) Ensure MapReduce functionality with Kerberos enabled
Date Wed, 28 Jan 2015 03:41:34 GMT


Christopher Tubbs commented on ACCUMULO-3513:

bq. Yes, we still need to trust that MapReduce is keeping the shared secret safe which we
know it does already.

Well, no... we don't know that it does this already. We have no idea how it may have been
compromised internally. All we know is that somehow, it gained access to a client's pre-negotiated
shared secret. We hope it did this by strongly authenticating with that client and that client
voluntarily giving it the shared secret, and that it was kept safe internally the entire time,
but we don't know that it did. We trust that it does this because we check (or should check)
its Kerberos credentials at the transport layer.

bq. The ability to expire a shared secret gives us some more confident that the shared secret
won't be reused by some unwanted party.

I agree, but we still need to ensure that the layer in between Accumulo and the real client
is trustworthy and is handling the client's credentials properly. My only point was that if
we already trust that layer to do that (which we definitely need to do... and not just any
Kerberos principal can be trusted), it's not much of a stretch to just trust that it is *acting
on behalf of user X, simply because it says so*. The extra, expirable, shared secret is nice,
but it doesn't get is *much* further than what we can do without it, in my opinion. An expirable
characteristic is a benefit (if it wasn't expirable, it wouldn't have any value at all). Other
characteristics, like having attributes which include specific authorizations that shared
secret is allowed to be used for, is even better (eg. instead of "you're allowed to act as
me", you get "you're allowed to act as me to query this table").

bq. We don't need a whitelist mechanism unless you're not trusting YARN itself which doesn't
make any sense to me (which I think you already agree on)

No, that's precisely the layer I don't trust without a whitelist. It still needs to authenticate
with Kerberos... the transport layer requires it... and not *all* Kerberos principals should
be allowed to freely use some other user's delegation token, just because they *somehow* got
ahold of one.

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