[DAC] HDFS and ZK access delegation
-----------------------------------
Key: HBASE-2420
URL: https://issues.apache.org/jira/browse/HBASE-2420
Project: Hadoop HBase
Issue Type: Sub-task
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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
