Newer releases of Apache HBase (TM) (>= 0.92) support optional SASL authentication of clients[20].
This describes how to set up Apache HBase and clients for connection to secure HBase resources.
You need to have a working Kerberos KDC.
A HBase configured for secure client access is expected to be running on top of a secured HDFS cluster. HBase must be able to authenticate to HDFS services. HBase needs Kerberos credentials to interact with the Kerberos-enabled HDFS daemons. Authenticating a service should be done using a keytab file. The procedure for creating keytabs for HBase service is the same as for creating keytabs for Hadoop. Those steps are omitted here. Copy the resulting keytab files to wherever HBase Master and RegionServer processes are deployed and make them readable only to the user account under which the HBase daemons will run.
A Kerberos principal has three parts, with the form
username/fully.qualified.domain.name@YOUR-REALM.COM
. We
recommend using hbase
as the username portion.
The following is an example of the configuration properties for
Kerberos operation that must be added to the
hbase-site.xml
file on every server machine in the
cluster. Required for even the most basic interactions with a
secure Hadoop configuration, independent of HBase security.
<property> <name>hbase.regionserver.kerberos.principal</name> <value>hbase/_HOST@YOUR-REALM.COM</value> </property> <property> <name>hbase.regionserver.keytab.file</name> <value>/etc/hbase/conf/keytab.krb5</value> </property> <property> <name>hbase.master.kerberos.principal</name> <value>hbase/_HOST@YOUR-REALM.COM</value> </property> <property> <name>hbase.master.keytab.file</name> <value>/etc/hbase/conf/keytab.krb5</value> </property>
Each HBase client user should also be given a Kerberos principal. This
principal should have a password assigned to it (as opposed to a
keytab file). The client principal's maxrenewlife
should
be set so that it can be renewed enough times for the HBase client
process to complete. For example, if a user runs a long-running HBase
client process that takes at most 3 days, we might create this user's
principal within kadmin
with: addprinc -maxrenewlife
3days
Long running daemons with indefinite lifetimes that require client
access to HBase can instead be configured to log in from a keytab. For
each host running such daemons, create a keytab with
kadmin
or kadmin.local
. The procedure for
creating keytabs for HBase service is the same as for creating
keytabs for Hadoop. Those steps are omitted here. Copy the resulting
keytab files to where the client daemon will execute and make them
readable only to the user account under which the daemon will run.
Add the following to the hbase-site.xml
file on every server machine in the cluster:
<property> <name>hbase.security.authentication</name> <value>kerberos</value> </property> <property> <name>hbase.security.authorization</name> <value>true</value> </property> <property> <name>hbase.coprocessor.region.classes</name> <value>org.apache.hadoop.hbase.security.token.TokenProvider</value> </property>
A full shutdown and restart of HBase service is required when deploying these configuration changes.
Add the following to the hbase-site.xml
file on every client:
<property> <name>hbase.security.authentication</name> <value>kerberos</value> </property>
The client environment must be logged in to Kerberos from KDC or
keytab via the kinit
command before communication with
the HBase cluster will be possible.
Be advised that if the hbase.security.authentication
in the client- and server-side site files do not match, the client will
not be able to communicate with the cluster.
Once HBase is configured for secure RPC it is possible to optionally
configure encrypted communication. To do so, add the following to the
hbase-site.xml
file on every client:
<property> <name>hbase.rpc.protection</name> <value>privacy</value> </property>
This configuration property can also be set on a per connection basis.
Set it in the Configuration
supplied to
HTable
:
Configuration conf = HBaseConfiguration.create(); conf.set("hbase.rpc.protection", "privacy"); HTable table = new HTable(conf, tablename);
Expect a ~10% performance penalty for encrypted communication.
Add the following to the hbase-site.xml
file for every Thrift gateway:
<property> <name>hbase.thrift.keytab.file</name> <value>/etc/hbase/conf/hbase.keytab</value> </property> <property> <name>hbase.thrift.kerberos.principal</name> <value>$USER/_HOST@HADOOP.LOCALDOMAIN</value> </property>
Substitute the appropriate credential and keytab for $USER and $KEYTAB respectively.
The Thrift gateway will authenticate with HBase using the supplied credential. No authentication will be performed by the Thrift gateway itself. All client access via the Thrift gateway will use the Thrift gateway's credential and have its privilege.
Add the following to the hbase-site.xml
file for every REST gateway:
<property> <name>hbase.rest.keytab.file</name> <value>$KEYTAB</value> </property> <property> <name>hbase.rest.kerberos.principal</name> <value>$USER/_HOST@HADOOP.LOCALDOMAIN</value> </property>
Substitute the appropriate credential and keytab for $USER and $KEYTAB respectively.
The REST gateway will authenticate with HBase using the supplied credential. No authentication will be performed by the REST gateway itself. All client access via the REST gateway will use the REST gateway's credential and have its privilege.
It should be possible for clients to authenticate with the HBase cluster through the REST gateway in a pass-through manner via SPEGNO HTTP authentication. This is future work.
[20] See also Matteo Bertozzi's article on Understanding User Authentication and Authorization in Apache HBase.