accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Slacum (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-4306) Support Kerberos authentication terminating at Accumulo
Date Tue, 10 May 2016 03:32:12 GMT


William Slacum commented on ACCUMULO-4306:

I think both of those points are really the same thing, which is "Can't a process running
on the cluster that isn't Accumulo read backing files?" The answer is most likely yes, given
a couple of circumstances:

1) Any user in the accumulo group will be able to read backing files. Authentication is a
non-factor for any such process. Potentially using something like Ranger would allow stricter
authorization policies to mitigate this. 

2) Without HDFS authentication enabled, a user could masquerade as another user via webhdfs
and that allows them to get around the authorization restriction mentioned above. In my use
case, we have some other safeguards in place to mitigate this, such as cell level encryption
that would require credentials external to both HDFS & Accumulo. 

For clarity's sake, when I say "user" I mean a user as HDFS would see it. I was not referring
an Accumulo user, which is, by default, a synthetic account in ZooKeeper. As the architecture
currently sits, only a subset of users (the Accumulo service principals, {{accumulo/HOST@REALM}})
interact with HDFS. Mostly I'm trying to get around the fact that "security" is either "on"
or "off" for all of HDFS, and I have specific read paths through Accumulo for external clients
that I'd prefer be strongly authenticated so they can get their proper authorizations. 

I was thinking about whether or not an encryption zone over Accumulo's data directory would
help as well, but so long as a user can pretend to be another user, they'd be able to do #2
to decrypt the directory's contents.

I believe that the multi-volume case *should* work correctly right now. So long as each NN
process is running as its own service principal, SASL+GSSAPI should be able to handle negotiation
tickets between a given TServer (as {{accumulo/$HOST@REALM}}) and the NN as if it were any
other service.

Would an update to our documentation/user manual that outlines the consequences of security
configurations (both current and those as a result of this ticket) help sway you one way or
the other? I think there's already gaps in our current capabilities now that are undocumented,
and this would just add more unknown variables. Specifically you've mentioned reading backing
files, but there are other concerns from Accumulo's perspective (such as user authorizations)
that are a separate class of protection mechanisms which I'm also trying to consider.

As as always, I appreciate the comments Sean :)

> Support Kerberos authentication terminating at Accumulo
> -------------------------------------------------------
>                 Key: ACCUMULO-4306
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: core, rpc
>            Reporter: William Slacum
>            Assignee: William Slacum
>              Labels: authentication, kerberos
>             Fix For: 1.8.0
> We currently support Kerberos authentication via SASL+GSSAPI. Due to an implementation
detail, turning it on requires also enabling Kerberos for HDFS.
> This ticket proposes changing the implementation to avoid needing to turn on Kerberos
authentication for HDFS, but still (optionally) using it. Mostly, I think this boils down
to replacing uses of {{UserGroupInformation}} with {{Subject}} references. There are couple
places (specifically around creating delegation tokens for use with a Kerberos-enabled Hadoop
cluster) where `UserGroupInformation` may need to stick around.

This message was sent by Atlassian JIRA

View raw message