[ 
https://issues.apache.org/jira/browse/ACCUMULO-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277424#comment-15277424
 ] 

Sean Busbey commented on ACCUMULO-4306:
---------------------------------------

Could you expand a little more on the likely usecases for this? I'm having 
trouble following and this seems like a pathway to easy security compromises.

1) In the case of HDFS not being exposed to an external network, wouldn't this 
change allow a user-submitted coprocessor executing server side to read 
arbitrary backing files?

2) In the case of a multi-tenant deploy of HDFS where Accumulo requires 
kerberos but other tenants don't, wouldn't lacking kerberos on HDFS mean that 
other tenants could read backing files? Why would Accumulo then have a 
requirement for kerberos for just its tenants? Wouldn't it also have the same 
problem as in #1?

Perhaps a better reason for the same changes needed here: how do we handle 
authenticating the TServers to multiple HDFS instances in a multi-volume 
deployment? Right now, I suspect they'd have to all use the same 
keytab/principal?

> Support Kerberos authentication terminating at Accumulo
> -------------------------------------------------------
>
>                 Key: ACCUMULO-4306
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4306
>             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
(v6.3.4#6332)

Reply via email to