[
https://issues.apache.org/jira/browse/HBASE-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-2420.
-----------------------------------
Resolution: Not a Problem
Should have been a brainstorming JIRA. Storm fizzled out
> [DAC] HDFS and ZK access delegation (isolation)
> -----------------------------------------------
>
> Key: HBASE-2420
> URL: https://issues.apache.org/jira/browse/HBASE-2420
> Project: HBase
> Issue Type: Sub-task
> Components: security
> Reporter: Andrew Purtell
>
> HBase security will be in part layered on top of HDFS security, and whatever
> ZK offers as well. For sake of discussion we presume both HDFS and ZK use a
> Kerberos based authentication and authorization model, as proposed in the
> Hadoop Security Architecture document. There are two basic options for that,
> fine- or coarse-grained:
> h4. Coarse
> There could simply be a single delegation token granted to a HBase cluster
> from HDFS and ZK for all operations on behalf of all possible users of the
> HBase cluster. From the perspective of HDFS and ZK, there is only a single
> principal for each cluster.
> h4. Fine
> The HBase master could manage and renew HDFS and ZK delegation tokens on
> behalf of users authenticated to HBase via Kerberos. So when a client
> authenticates via KRB to the HMaster when looking up region locations as the
> first step to any HBase access, the HMaster would get a delegation token from
> the NameNode on behalf of the user. (The user would then hand the delegation
> token to the HRegionServers to allow access to store data via their embedded
> DFSClients.) It would be ideal if ZooKeeper authentication and authorization
> could tie in seamlessly. For example, at the same time the HMaster is getting
> a delegation token for the user for HDFS, it could also get another token for
> ZK on behalf of the user. A wrinkle here is token renewal. If a user
> transacts with a HRegionServer with an expired token, the HRegionServer would
> renew the token (or ask the HMaster to renew the token if superuser should
> not be delegated from HMaster to HRegionServer) transparently with the
> NameNode on behalf of the user. Something like that would be necessary on the
> ZK side also. To support this model, the HRegionServers and HMaster (or just
> HMaster) must act as a superuser principal capable of impersonating user
> principals. Presumably, with the ZK ensemble also. Thus ZK, like HDFS, must
> provide methods for a superuser to act on behalf of others. HDFS will have
> this facility.
> There are pros and cons for each approach. Coarse obviously is much more
> simple to implement and reason about. But it requires more trust in HBase to
> maintain isolation between users than the fine-grained approach. With the
> fine-grained approach, the regionservers get HDFS and ZK delegation tokens
> from the HBase client and this allows a policy where files and znodes created
> by one user+group cannot be read or written by another at the DFS (store)
> level or the ZK level. Assume group level permissions. Thus you can reason
> about isolation further down the stack, not just from client->HBase, but
> client->HBase->HDFS and client->ZK and client->HBase->ZK.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
