Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <1688975745.50601270669953521.JavaMail.jira@brutus.apache.org>
Date: Wed, 7 Apr 2010 19:52:33 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Created: (HBASE-2420) [DAC] HDFS and ZK access delegation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

[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 whateve=
r 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 th=
e Hadoop Security Architecture document. There are two basic options for th=
at, 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 be=
half of users authenticated to HBase via Kerberos. So when a client authent=
icates 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 th=
e 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 embedde=
d DFSClients.) It would be ideal if ZooKeeper authentication and authorizat=
ion could tie in seamlessly. For example, at the same time the HMaster is g=
etting 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 u=
ser 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 t=
he NameNode on behalf of the user. Something like that would be necessary o=
n 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 wil=
l have this facility.=20

There are pros and cons for each approach. Coarse obviously is much more si=
mple to implement and reason about. But it requires more trust in HBase to =
maintain isolation between users than the fine-grained approach. With the f=
ine-grained approach, the regionservers get HDFS and ZK delegation tokens f=
rom the HBase client and this allows a policy where files and znodes create=
d 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 c=
lient->HBase->HDFS and client->ZK and client->HBase->ZK.=20

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.