Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 14 Oct 2011 03:46:11 +0000 (UTC)
From: "Daniel Lescohier (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1907553631.12633.1318563971827.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-2418) add support for ZooKeeper
 authentication
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Daniel Lescohier commented on HBASE-2418:
-----------------------------------------

The purpose of this issue is to prevent other (non-hbase) applications from accidentally writing to hbase's znodes on a multi-tenant zookeeper cluster [so this isn't really related to HBASE-1697 or HBASE-3025].

I don't think we have to get too fancy; Zookeeper's Digest authentication would be sufficient for this use-case.

Assuming that Hbase clients only need read-only access to hbase's zookeeper znodes, then this simple approache would be sufficient:

Add a configuration property: hbase.zookeepeer.digest.auth.secrets.filename.

The secret will go in a separate file so that you can deploy the secret only on the hbase servers; you don't want the secret directly in the hbase config file, since the hbase config file is also deployed to hbase clients.

The contents of the secrets file will have one line with the data: username:password.

The Hbase server code (master/regionserver) will change to:

On server startup:
-----------------

if the property exists and the file exists and the file is readable:
  open the file and read the contents
  save the secret in server config state so that it can be used when connecting to zookeeper

On connecting to zookeeper:
--------------------------

right after connected to zookeeper:
  if we have a digest secret from server startup:
    zk.addAuthInfo("digest", digest_secret);
    save in server config state:
      create_acl_list = ZooDefs.Ids.READ_ACL_UNSAFE.clone();
      create_acl_list.addAll(ZooDefs.Ids.CREATOR_ALL_ACL);
      // allows world: read access; hbase servers: all privs
  else: // don't use authentication
    save in server configuration state:
      create_acl_list = ZooDefs.Ids.OPEN_ACL_UNSAFE;

On creating a node in zookeeper:
-------------------------------
  pass create_acl_list as the acl parameter when calling Zookeeper.create()

                
> add support for ZooKeeper authentication
> ----------------------------------------
>
>                 Key: HBASE-2418
>                 URL: https://issues.apache.org/jira/browse/HBASE-2418
>             Project: HBase
>          Issue Type: Improvement
>          Components: master, regionserver
>            Reporter: Patrick Hunt
>            Assignee: Eugene Koontz
>            Priority: Critical
>
> Some users may run a ZooKeeper cluster in "multi tenant mode" meaning that more than one client service would
> like to share a single ZooKeeper service instance (cluster). In this case the client services typically want to protect
> their data (ZK znodes) from access by other services (tenants) on the cluster. Say you are running HBase and Solr 
> and Neo4j, or multiple HBase instances, etc... having authentication/authorization on the znodes is important for both 
> security and helping to ensure that services don't interact negatively (touch each other's data).
> Today HBase does not have support for authentication or authorization. This should be added to the HBase clients
> that are accessing the ZK cluster. In general it means calling addAuthInfo once after a session is established:
> http://hadoop.apache.org/zookeeper/docs/current/api/org/apache/zookeeper/ZooKeeper.html#addAuthInfo(java.lang.String, byte[])
> with a user specific credential, often times this is a shared secret or certificate. You may be able to statically configure this
> in some cases (config string or file to read from), however in my case in particular you may need to access it programmatically,
> which adds complexity as the end user may need to load code into HBase for accessing the credential.
> Secondly you need to specify a non "world" ACL when interacting with znodes (create primarily):
> http://hadoop.apache.org/zookeeper/docs/current/api/org/apache/zookeeper/data/ACL.html
> http://hadoop.apache.org/zookeeper/docs/current/api/org/apache/zookeeper/ZooDefs.html
> Feel free to ping the ZooKeeper team if you have questions. It might also be good to discuss with some 
> potential end users - in particular regarding how the end user can specify the credential.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira