hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Update of "Hbase/HBaseTokenAuthentication" by GaryHelmling
Date Tue, 22 Mar 2011 23:05:32 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.

The "Hbase/HBaseTokenAuthentication" page has been changed by GaryHelmling.
The comment on this change is: Corrected zookeeper usage for actual implementation.
http://wiki.apache.org/hadoop/Hbase/HBaseTokenAuthentication?action=diff&rev1=2&rev2=3

--------------------------------------------------

   1. Server and client then use Token``Authenticator as the shared secret to negotiate DIGEST-MD5
authentication
  
  ==== Master Secret Key ====
- Authentication relies on a secret key generated at runtime on the master and used to generate
Authentication Tokens for clients.  Tokens will be generated on the master for Kerberos authenticated
clients, but token based authentication will need to be allowed on all masters and region
servers in a cluster.  So the master will need a means to distribute the secret key to other
cluster nodes.
+ Authentication relies on a secret key generated and held in memory on the RPC server and
used to generate Authentication Tokens for clients.  The secret key used to generate tokens
will be periodically rolled in order to limit exposure to brute-force reversing of the secret
key from token signatures.  However, to allow previously issued token to continue to work,
N previously generated keys will be retained, with the oldest removed on rolling when the
limit is reached.  In order to simplify coordination of the key rolling process, all RPC servers
in a cluster will select a "leader" which will perform the secret key rolling and expiration.
 
  
- The master will also need to write the secret key to semi-persistent storage in order for
authentication tokens to survive a cluster restart.  The keys themselves are by nature transient,
as the current master key will be periodically rolled to limit exposure to reverse engineering
from token secrets.  The last N keys will be maintained in order to validate existing tokens,
using a fixed size queue, with the oldest key dropped on insertion when full.
+ Authentication Tokens could be generated on RPC server holding the current secret key for
Kerberos authenticated clients, but authentication using this token will need to succeed on
all servers in a cluster.  So the leader node will need a means to distribute the secret key
changes to other cluster nodes.
  
- ZooKeeper will be used to broadcast master key changes throughout the cluster and to provide
key persistence between master restarts or failover.  Note that this depends on securing access
to the key znodes via Kerberos authentication and ZooKeeper ACLs.  Keys will be stored in
ZooKeeper, with one znode per key, using the structure:
+ The secret keys currently in use will also need to be available via semi-persistent storage
in order for validation of previously issued authentication tokens to survive a cluster restart.
 The keys themselves are by nature transient, due to the expiration policy.  But this will
allow any new RPC server to read in the currently in use keys on startup, and resume with
token generation and authentication.
+ 
+ ZooKeeper will be used to coordinate all three of these needs.
+ 
+ To coordinate leader node selection, RPC servers will race to obtain an ephemeral znode
on startup, with the successful node starting the key rolling and expiration thread:
  {{{
    <HBASE_ROOT>/
+       tokenauth/
+           znode('keymaster', serverName)
-       secretkey/
-           znode(keyID1, serialized DelegationKey1)
-           znode(keyID2, serialized DelegationKey2)
-           ...
  }}}
+ 
+ The process used is very similar to handling of the active HMaster.  If the server holding
the "keymaster" node dies or loses it's ZooKeeper session, the remaining nodes will again
race to claim the znode first.
+  
+ To broadcast master key changes throughout the cluster and to provide key persistence between
server restarts or failover, the leader will maintain a znode per secret key, with all other
nodes watching on changes to children of a known parent:
+ {{{
+   <HBASE_ROOT>/
+       tokenauth/
+           keys/
+               znode(keyID1, serialized DelegationKey1)
+               znode(keyID2, serialized DelegationKey2)
+               ...
+ }}}
+ 
+ Note that this depends on securing access to the key znodes via Kerberos authentication
of ZooKeeper clients and setting of ZooKeeper ACLs.
  
  ==== Implementation ====
   1. Extend {{{org.apache.hadoop.security.token.TokenIdentifier}}} with new HBase type

Mime
View raw message