Chapter 8. Secure Apache HBase

Table of Contents

8.1. Secure Client Access to Apache HBase
8.1.1. Prerequisites
8.1.2. Server-side Configuration for Secure Operation
8.1.3. Client-side Configuration for Secure Operation
8.1.4. Client-side Configuration for Secure Operation - Thrift Gateway
8.1.5. Configure the Thrift Gateway to Authenticate on Behalf of the Client
8.1.6. Client-side Configuration for Secure Operation - REST Gateway
8.1.7. REST Gateway Impersonation Configuration
8.2. Simple User Access to Apache HBase
8.2.1. Simple Versus Secure Access
8.3. Tags
8.4. Access Control
8.4.1. Prerequisites
8.4.2. Overview
8.4.3. Access Control Matrix
8.4.4. Server-side Configuration for Access Control
8.4.5. Cell level Access Control using Tags
8.4.6. Shell Enhancements for Access Control
8.5. Secure Bulk Load
8.6. Visibility Labels
8.6.1. Visibility Label Administration
8.6.2. Server Side Configuration
8.7. Transparent Server Side Encryption
8.7.1. Configuration
8.7.2. Setting Encryption on a CF
8.7.3. Data Key Rotation
8.7.4. Master Key Rotation

8.1. Secure Client Access to Apache HBase

Newer releases of Apache HBase (>= 0.92) support optional SASL authentication of clients. See also Matteo Bertozzi's article on Understanding User Authentication and Authorization in Apache HBase.

This describes how to set up Apache HBase and clients for connection to secure HBase resources.

8.1.1. Prerequisites

Hadoop Authentication Configuration

To run HBase RPC with strong authentication, you must set hbase.security.authentication to true. In this case, you must also set hadoop.security.authentication to true. Otherwise, you would be using strong authentication for HBase but not for the underlying HDFS, which would cancel out any benefit.

Kerberos KDC

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.

8.1.2. Server-side Configuration for Secure Operation

First, refer to Section 8.1.1, “Prerequisites” and ensure that your underlying HDFS configuration is secure.

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.

8.1.3. Client-side Configuration for Secure Operation

First, refer to Section 8.1.1, “Prerequisites” and ensure that your underlying HDFS configuration is secure.

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.

8.1.4. Client-side Configuration for Secure Operation - Thrift Gateway

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.

8.1.5. Configure the Thrift Gateway to Authenticate on Behalf of the Client

Section 8.1.4, “Client-side Configuration for Secure Operation - Thrift Gateway” describes how to authenticate a Thrift client to HBase using a fixed user. As an alternative, you can configure the Thrift gateway to authenticate to HBase on the client's behalf, and to access HBase using a proxy user. This was implemented in HBASE-11349 for Thrift 1, and HBASE-11474 for Thrift 2.

Limitations with Thrift Framed Transport

If you use framed transport, you cannot yet take advantage of this feature, because SASL does not work with Thrift framed transport at this time.

To enable it, do the following.

  1. Be sure Thrift is running in secure mode, by following the procedure described in Section 8.1.4, “Client-side Configuration for Secure Operation - Thrift Gateway”.

  2. Be sure that HBase is configured to allow proxy users, as described in Section 8.1.7, “REST Gateway Impersonation Configuration”.

  3. In hbase-site.xml for each cluster node running a Thrift gateway, set the property hbase.thrift.security.qop to one of the following three values:

    • auth-conf - authentication, integrity, and confidentiality checking

    • auth-int - authentication and integrity checking

    • auth - authentication checking only

  4. Restart the Thrift gateway processes for the changes to take effect. If a node is running Thrift, the output of the jps command will list a ThriftServer process. To stop Thrift on a node, run the command bin/hbase-daemon.sh stop thrift. To start Thrift on a node, run the command bin/hbase-daemon.sh start thrift.

8.1.6. Client-side Configuration for Secure Operation - REST Gateway

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.

8.1.7. REST Gateway Impersonation Configuration

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.

comments powered by Disqus