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

stack commented on HBASE-3615:
------------------------------

I took a read off the wiki page Gary.  The goals seem pretty impossible though 
I'm sure you'll pull it off.

bq. will need to persist somewhere (zookeeper?) to allow for master restarts 
and failover

ZK seems good for storing a small thing that does not change.  Will the key be 
generally available if its in zk?

Is there a 'secure' location in hdfs?

bq. could be on region checkin/heartbeats, though stack is removing those

Yes.  Trying.

bq. but do we really need to do token renewal

When would you need this?

Yes, as you note, for case of multiple masters, on failover, new master will 
need to be able to pick up the token.

bq. FileSystem.getCanonicalServiceName() is used as the alias for HDFS 
delegation tokens, what should we use?

Whats this?  We need name for cluster instance?  I suppose we can't use master 
ip plus port because could change with time.  The zk ensemble string plus the 
zk rootdir?  This is ugly -- zk1,zk2,zk3,zk4,zk5/hbase3 where hbase3 is the 
homedir in zk of the third cluster running against this ensemble -- in that 
what do you do if you are passed zk1,zk2,zk3 and zk1,zk2,zk3,zk4,zk5?  Are they 
the same ensemble.  I think so.

I can't comment on how secure it all is Gary.  I'm clueless on that stuff.

Doc. looks great.

> Implement token based DIGEST-MD5 authentication for MapReduce tasks
> -------------------------------------------------------------------
>
>                 Key: HBASE-3615
>                 URL: https://issues.apache.org/jira/browse/HBASE-3615
>             Project: HBase
>          Issue Type: New Feature
>          Components: ipc, security
>            Reporter: Gary Helmling
>            Assignee: Gary Helmling
>             Fix For: 0.92.0
>
>
> HBase security currently supports Kerberos authentication for clients, but 
> this isn't sufficient for map-reduce interoperability, where tasks execute 
> without Kerberos credentials.  In order to fully interoperate with map-reduce 
> clients, we will need to provide our own token authentication mechanism, 
> mirroring the Hadoop token authentication mechanisms.  This will require 
> obtaining an HBase authentication token for the user when the job is 
> submitted, serializing it to a secure location, and then, at task execution, 
> having the client or task code de-serialize the stored authentication token 
> and use that in the HBase client authentication process.
> A detailed implementation proposal is sketched out on the wiki:
> http://wiki.apache.org/hadoop/Hbase/HBaseTokenAuthentication

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to