Introduction

Rest Gateway is an important component in Apache HBase. It provides a HTTP Rest endpoint that allows users to use Rest API to access HBase cluster, translating Rest API calls from end users to naive requests to HBase cluster. Many common HBase operations can be carried out using Rest API. For example, create HBase table, put data into HBase table and retrieve data from HBase table.

In this blog we will focus on the security aspect of HBase Rest Gateway: how it fits into the overall HBase security and what can be done to secure HBase gateway.
HBase natively supports Kerberos authentication and access authorization. HBase Rest Gateway provides Kerberos authentication support for users accessing HBase via the Rest Gateway in seamless integration with HBase native security.

In some deployment scenarios, HBase Rest Gateway is the only access to HBase while the other servers are blocked behind firewall. The security feature in HBase Rest Gateway is particularly useful in such cases.

HBase Rest Gateway acts as a proxy server between end users and HBase cluster. In a HBase deployment that includes Rest Gateway, the Rest Gateway would be running under a fixed user id or principal, for example, ‘hbase_rest_server’, or simply ‘hbase’. In a secure configuration, the Rest Gateway authenticates the user coming to it via HTTP Rest call. If the user is successfully authenticated, the user id will be forwarded to HBase master or region servers. The Rest Gateway always ‘impersonates’ the Rest client user in a secure configuration. The HBase server then checks access control or authorization for this Rest client user id to perform the requested actions.

The security mechanism supported by HBase Rest Gateway is SPNEGO HTTP authentication.

HBaseRestRestSecurity1

Note It is also recommended that the Rest Gateway is secured by SSL for transport security, which is not covered by this blog.

Configuration

With the understanding of the overall security picture, let’s discuss the configuration to enable the security. HBase Rest Gateway can be deployed on different hosts than the HBase cluster (mater and region servers). If this is the case, some of the security properties need to be in the hbase-site.xml for the Rest Gateway, some need to in the configuration file for the HBase cluster (Master and region servers).

The following properties need to be in the hbase-site.xml on the Rest Gateway.

1. Configuration to enable Rest Gateway security

    <property>
    <name>hbase.security.authentication</name>
    <value>kerberos</value>
    </property>

This is the overall switch to enable Rest Gateway security.

2. Configuration to enable Rest Gateway’s communication with the HBase master and region servers

    <property>
    <name>hbase.rest.kerberos.principal</name>
    <value>hbase/_HOST@IBM.COM</value>
    </property>
    <property>
    <name>hbase.rest.keytab.file</name>
    <value>/etc/security/keytabs/hbase.service.keytab</value>
    </property>

‘hbase’ is the id used to run the Rest Gateway. The keytab file must contain this principal and its keys.

3. Configuration to enable Rest Gateway’s SPNEGO HTTP authentication with Rest client users.

    <property>
    <name>hbase.rest.authentication.type</name>
    <value>kerberos</value>
    </property>
    <property>
    <name>hbase.rest.authentication.kerberos.principal</name>
    <value> HTTP/_HOST@IBM.COM</value>
    </property>
    <property>
    <name>hbase.rest.authentication.kerberos.keytab</name>
    <value>/etc/security/keytabs/hbase.service.keytab</value>
    </property>

The SPNEGO service principal is HTTP. The keytab file must contain this principal and its keys.

4. Configuration to enable proxy user support for Rest Gateway.

    <property>
    <name>hadoop.proxyuser.hbase.groups</name>
    <value>group1,group2</value>
    </property>
    <property>
    <name>hadoop.proxyuser.hbase.hosts</name>
    <value>host1,host2</value>
    </property>

The above properties need to be in the hbase-site.xml on the HBase master and region servers. Or they can be in the core-site.xml that is on the class path of the HBase servers.
They specify that the user named ‘hbase’ can connect only from host1 and host2 to impersonate a user belonging to group1 and group2. ‘*’ can be used as wildcard value for the groups and hosts. The property ‘ hadoop.proxyuser.hbase.users’ can be used instead to specify the users that ‘hbase’ can impersonate.
Note that this impersonation checking is done at the destination HBase server. After that, the server will check the access authorization of the impersonated user (end user id) to perform the requested action.
The secure configuration of the HBase master and region servers is not the focus of this blog, but for completeness, the necessary configuration is listed below. After access control is enabled the appropriate authorization/permissions need to be granted to the end users.

5. Configuration to enable HBase native security.
The following configuration needs to be in the hbase-site.xml on the HBase master and region servers.

    <property>
    <name>hbase.security.authentication</name>
    <value>kerberos</value>
    </property>
    <property>
    <name>hbase.security.authorization</name>
    <value>true</value>
    </property>
    <property>
    <name>hbase.coprocessor.master.classes</name>
    <value>org.apache.hadoop.hbase.security.access.AccessController</value>
    </property>
    <property>
    <name>hbase.coprocessor.region.classes</name>
    <value>org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint,org.apache.hadoop.hbase.security.access.AccessController</value>
    </property>

Tip: The SecurityAuth.audit file in the HBase server log directory shows the security audit of the incoming connections and access control actions. Enable the following property in the ‘ Security audit appender’ section of the HBase server log4j. properties.
log4j.logger.SecurityLogger.org.apache.hadoop.hbase.security.access.AccessController=TRACE

Demo 1

A ‘kinit’ is needed to obtain Kerberos credential before running the commands below. curl supports SPNEGO with the — negotiate option.

    curl –negotiate -u : http://bdavm207.svl.ibm.com:8091/status/cluster
    2 live servers, 0 dead servers, 2.5000 average load
    2 live servers
    bdavm207.svl.ibm.com:16020 1462682731044
    requests=0, regions=3
    heapSizeMB=373
    maxHeapSizeMB=4044
    curl –negotiate -u : http://bdavm207.svl.ibm.com:8091/table1/schema
    { NAME=> ‘table1’, IS_META => ‘false’, COLUMNS => [ { NAME => ‘family1’, BLOOMFILTER => ‘ROW’, VERSIONS => ‘1’, IN_MEMORY => ‘false’, KEEP_DELETED_CELLS => ‘FALSE’, DATA_BLOCK_ENCODING => ‘NONE’, TTL => ‘2147483647’, COMPRESSION => ‘NONE’, MIN_VERSIONS => ‘0’, BLOCKCACHE => ‘true’, BLOCKSIZE => ‘65536’, REPLICATION_SCOPE => ‘0’ } ] }
    curl –negotiate -u : -X PUT -H "Accept: text/xml" -H "Content-Type: text/xml" -d ‘<TableSchema name="table1"><ColumnSchema name="cf" /></TableSchema>’ "http://bdavm207.svl.ibm.com:8091/table1/schema"

Tip: Use curl -i -v options, which shows the negotiate handshake, for trouble shooting.

Rest Gateway ‘doAs’ Security

HBase Rest Gateway supports a special ‘doAs’ impersonation. The Rest client can submit a Rest call that has a ‘doAs’ in the query string.

HBaseRestSecurity2

In the illustration above, the Rest request is submitted by user1 but has ‘doAs=user2’ in it. Rest Gateway will authenticate user1 then check that user1 can impersonate user2. If it is all successful, it will forward user2 to the HBase servers to check for authorization to perform the action.

6. Additional Configuration to enable Rest Gateway ‘doAs’

The following configuration needs to be in the hbase-site.xml on the Rest Gateway. Replace ‘user1’ with the user who want to ‘doAs’ another user. The user’s ability to impersonate is checked by the Rest Gateway.

    <property>
    <name>hbase.rest.support.proxyuser</name>
    <value>true</value>
    </property>
    <property>
    <name>hadoop.proxyuser.user1.groups</name>
    <value>*</value>
    </property>
    <property>
    <name>hadoop.proxyuser.user1.hosts</name>
    <value>*</value>
    </property>

Demo 2

kinit with ‘user1’ principal
curl –negotiate -u : http://bdavm207.svl.ibm.com:8091/status/cluster?doAs=user2

2 comments on"HBase Rest Gateway Security"

  1. sivanagamahesh October 27, 2016

    Hi,
    An HBase configured for secure client access is expected to be running on top of a secure 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 key tab file. The procedure for creating key tabs for HBase service is the same as for creating key tabs for Hadoop. Those steps are omitted here. Copy the resulting key tab 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.Thanks for sharing me nice information.

Join The Discussion

Your email address will not be published. Required fields are marked *