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. Client-side Configuration for Secure Operation - REST Gateway
8.1.6. 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. Server-side Configuration for Access Control
8.4.4. Cell level Access Control using Tags
8.4.5. 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[22].

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

8.1.1. Prerequisites

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

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

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. 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.6. 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