hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HBASE-2420) [DAC] HDFS and ZK access delegation (isolation)
Date Sat, 19 Jul 2014 00:47:40 GMT

     [ 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

View raw message