hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jiraposter@reviews.apache.org (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-2418) add support for ZooKeeper authentication
Date Tue, 15 Nov 2011 22:09:53 GMT

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

jiraposter@reviews.apache.org commented on HBASE-2418:

bq.  On 2011-11-15 20:12:11, Michael Stack wrote:
bq.  > pom.xml, line 794
bq.  > <https://reviews.apache.org/r/2837/diff/1/?file=58410#file58410line794>
bq.  >
bq.  >     What are the implications of shipping a 3.4 zk snapshot with 0.92 hbase?  Will
a 3.4 client be able to talk to a 3.3.3. ensemble?

bq.  Will a 3.4 client be able to talk to a 3.3.3. ensemble?

No, but we can make this change conditional on enabling the Maven '-P security' profile. I
should have done that already.

bq.  On 2011-11-15 20:12:11, Michael Stack wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java, line 668
bq.  > <https://reviews.apache.org/r/2837/diff/1/?file=58412#file58412line668>
bq.  >
bq.  >     So, how do we guarantee that our session w/ zk is secure if the hbase install
is configured secure?  What is in place to prevent our connecting insecure to a zk ensemble
if the hbase is supposed to be secure?

ZooKeeper auth is independent of RPC auth.

Connecting insecurely to a secure ZK ensemble is totally acceptable from a non-HBase point
of view. It allows backwards compatibility over in ZK land.

Even when running secure HBase, most clients would have no trouble even if connecting insecurely
to ZK; only the Master and RegionServers would want to authenticate and set ACLs accordingly.

We could add another check elsewhere in the Master and RegionServer (via ZKUtil presumably)
if HBase security is enabled to test that ACLs are set up, but this won't let someone run
with an insecure ZooKeeper version, maybe 3.3.3 or whatever. Maybe someone will want that.
I think it's a user concern.

bq.  On 2011-11-15 20:12:11, Michael Stack wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java, line 676
bq.  > <https://reviews.apache.org/r/2837/diff/1/?file=58412#file58412line676>
bq.  >
bq.  >     Would suggest filing the jira and reference it here.

Eugene opened HBASE-4791. Will make a note.

bq.  On 2011-11-15 20:12:11, Michael Stack wrote:
bq.  > src/test/java/org/apache/hadoop/hbase/zookeeper/TestZooKeeperACL.java, line 77
bq.  > <https://reviews.apache.org/r/2837/diff/1/?file=58415#file58415line77>
bq.  >
bq.  >     This is an insecure cluster using a secure zk?

ZooKeeper auth is independent of RPC auth.

- Andrew

This is an automatically generated e-mail. To reply, visit:

On 2011-11-15 19:43:37, Andrew Purtell wrote:
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/2837/
bq.  -----------------------------------------------------------
bq.  (Updated 2011-11-15 19:43:37)
bq.  Review request for hbase, Gary Helmling and Eugene Koontz.
bq.  Summary
bq.  -------
bq.  These changes add support for protecting the state of HBase znodes on a multi-tenant
ZooKeeper cluster. This support requires ZK 3.4.0, currently at RC2. It is a companion patch
to HBASE-2742 (secure RPC), and HBASE-3025 (Coprocessor based access control).
bq.  SASL authentication of ZooKeeper clients with the quorum is handled in the ZK client
independently of HBase concerns. To enable strong ZK authentication, one must create a suitable
JaaS configuration, for example:
bq.    Server {
bq.      com.sun.security.auth.module.Krb5LoginModule required
bq.      useKeyTab=true
bq.      keyTab="/etc/hbase/conf/hbase.keytab"
bq.      storeKey=true
bq.      useTicketCache=false
bq.      principal="zookeeper/$HOSTNAME";
bq.    };
bq.    Client {
bq.      com.sun.security.auth.module.Krb5LoginModule required
bq.      useKeyTab=true
bq.      useTicketCache=false
bq.      keyTab="/etc/hbase/conf/hbase.keytab"
bq.      principal="hbase/$HOSTNAME";
bq.    };
bq.  and then configure both the client and server processes to use it, for example in hbase-site.xml:
bq.    HBASE_OPTS="${HBASE_OPTS} -Djava.security.auth.login.config=/etc/hbase/conf/jaas.conf"
bq.    HBASE_OPTS="${HBASE_OPTS} -Dzookeeper.kerberos.removeHostFromPrincipal=true"
bq.    HBASE_OPTS="${HBASE_OPTS} -Dzookeeper.kerberos.removeRealmFromPrincipal=true"
bq.  HBase will then secure all znodes but for a few world-readable read-only ones needed
for clients to look up region locations. All internal cluster operations will be protected
from unauthenticated ZK clients, or clients not authenticated to the HBase principal. Presumably
the only ZK clients authenticated to the HBase principal will be those embedded in the master
and regionservers.
bq.  There is extraneous whitespace in code surrounding these changes.
bq.  This addresses bug HBASE-2418.
bq.      https://issues.apache.org/jira/browse/HBASE-2418
bq.  Diffs
bq.  -----
bq.    src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java f613ba9 
bq.    src/test/java/org/apache/hadoop/hbase/zookeeper/TestZooKeeperACL.java PRE-CREATION

bq.    src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWatcher.java a75cf87 
bq.    src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java bb67e53 
bq.    pom.xml c74ce25 
bq.    src/main/java/org/apache/hadoop/hbase/zookeeper/MiniZooKeeperCluster.java 05abeb7 
bq.  Diff: https://reviews.apache.org/r/2837/diff
bq.  Testing
bq.  -------
bq.  These changes are running in production at Trend Micro, using a snapshot build of ZooKeeper
bq.  New unit test TestZooKeeperACL passes 100 iterations. All test pass not otherwise currently
failing on trunk.
bq.  Thanks,
bq.  Andrew

> 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
>              Labels: security, zookeeper
> 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
> 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,
> 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


View raw message