Table of Contents
Newer releases of Apache HBase (>= 0.92) support optional SASL authentication of clients[1].
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> <!-- TODO: This may need to be HTTP/_HOST@<REALM> and _HOST may not work. You may have to put the concrete full hostname. --> </property>
Substitute the appropriate credential and keytab for $USER and $KEYTAB respectively.
In order to use the Thrift API principal to interact with HBase, it is also necessary to
add the hbase.thrift.kerberos.principal
to the _acl_
table. For
example, to give the Thrift API principal, thrift_server
, administrative
access, a command such as this one will suffice:
grant 'thrift_server', 'RWCA'
For more information about ACLs, please see the Access Control section
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.
In order to use the REST API principal to interact with HBase, it is also necessary to
add the hbase.rest.kerberos.principal
to the _acl_
table. For
example, to give the REST API principal, rest_server
, administrative access, a
command such as this one will suffice:
grant 'rest_server', 'RWCA'
For more information about ACLs, please see the Access Control section
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.
By default, the REST gateway doesn't support impersonation. It accesses the HBase on behalf of clients as the user configured as in the previous section. To the HBase server, all requests are from the REST gateway user. The actual users are unknown. You can turn on the impersonation support. With impersonation, the REST gateway user is a proxy user. The HBase server knows the acutal/real user of each request. So it can apply proper authorizations.
To turn on REST gateway impersonation, we need to configure HBase servers (masters and region servers) to allow proxy users; configure REST gateway to enable impersonation.
To allow proxy users, add the following to the hbase-site.xml
file for
every HBase server:
<property> <name>hadoop.security.authorization</name> <value>true</value> </property> <property> <name>hadoop.proxyuser.$USER.groups</name> <value>$GROUPS</value> </property> <property> <name>hadoop.proxyuser.$USER.hosts</name> <value>$GROUPS</value> </property>
Substitute the REST gateway proxy user for $USER, and the allowed group list for $GROUPS.
To enable REST gateway impersonation, add the following to the
hbase-site.xml
file for every REST gateway.
<property> <name>hbase.rest.authentication.type</name> <value>kerberos</value> </property> <property> <name>hbase.rest.authentication.kerberos.principal</name> <value>HTTP/_HOST@HADOOP.LOCALDOMAIN</value> </property> <property> <name>hbase.rest.authentication.kerberos.keytab</name> <value>$KEYTAB</value> </property>
Substitute the keytab for HTTP for $KEYTAB.
[1] See also Matteo Bertozzi's article on Understanding User Authentication and Authorization in Apache HBase.