Managing HBase Security

This topic pulls together content also found elsewhere which relates to configuring and using HBase in a secure environment. For the most part, securing an HBase cluster is a one-way operation, and moving from a secure to an unsecure configuration should not be attempted without contacting Cloudera support for guidance.

HBase Authentication

To configure HBase security, complete the following tasks:

  1. Configure HBase Authentication: You must establish a mechanism for HBase servers and clients to securely identify themselves with HDFS, ZooKeeper, and each other. This ensures that hosts are who they claim to be.
    The following sections describe how to use Apache HBase and CDH 5 with Kerberos security:
  2. Configure HBase Authorization: You must establish rules for the resources that clients are allowed to access. For more information, see Configuring HBase Authorization.

Using the Hue HBase App

Hue includes an HBase App that allows you to interact with HBase through a Thrift proxy server. Because Hue sits between the Thrift server and the client, the Thrift server assumes that all HBase operations come from the hue user and not the client. To ensure that users in Hue are only allowed to perform HBase operations assigned to their own credentials, and not those of the hue user, you must enable HBase impersonation. For more information about the how to enable doAs Impersonation for the HBase Browser Application, see Enabling the HBase Browser Application with doAs Impersonation.

Configuring HBase Authorization

After you have configured HBase authentication as described in the previous section, you must establish authorization rules for the resources that a client is allowed to access. HBase currently allows you to establish authorization rules at the table, column and cell-level. Cell-level authorization is fully supported since CDH 5.2.

Continue reading:

Understanding HBase Access Levels

HBase access levels are granted independently of each other and allow for different types of operations at a given scope.
  • Read (R) - can read data at the given scope
  • Write (W) - can write data at the given scope
  • Execute (X) - can execute coprocessor endpoints at the given scope
  • Create (C) - can create tables or drop tables (even those they did not create) at the given scope
  • Admin (A) - can perform cluster operations such as balancing the cluster or assigning regions at the given scope
The possible scopes are:
  • Superuser - superusers can perform any operation available in HBase, to any resource. The user who runs HBase on your cluster is a superuser, as are any principals assigned to the configuration property hbase.superuser in hbase-site.xml on the HMaster.
  • Global - permissions granted at global scope allow the admin to operate on all tables of the cluster.
  • Namespace - permissions granted at namespace scope apply to all tables within a given namespace.
  • Table - permissions granted at table scope apply to data or metadata within a given table.
  • ColumnFamily - permissions granted at ColumnFamily scope apply to cells within that ColumnFamily.
  • Cell - permissions granted at Cell scope apply to that exact cell coordinate. This allows for policy evolution along with data. To change an ACL on a specific cell, write an updated cell with new ACL to the precise coordinates of the original. If you have a multi-versioned schema and want to update ACLs on all visible versions, you'll need to write new cells for all visible versions. The application has complete control over policy evolution. The exception is append and increment processing. Appends and increments can carry an ACL in the operation. If one is included in the operation, then it will be applied to the result of the append or increment. Otherwise, the ACL of the existing cell being appended to or incremented is preserved.
The combination of access levels and scopes creates a matrix of possible access levels that can be granted to a user. In a production environment, it is useful to think of access levels in terms of what is needed to do a specific job. The following list describes appropriate access levels for some common types of HBase users. It is important not to grant more access than is required for a given user to perform their required tasks.
  • Superusers - In a production system, only the HBase user should have superuser access. In a development environment, an administrator may need superuser access in order to quickly control and manage the cluster. However, this type of administrator should usually be a Global Admin rather than a superuser.

  • Global Admins - A global admin can perform tasks and access every table in HBase. In a typical production environment, an admin should not have Read or Write permissions to data within tables.

    • A global admin with Admin permissions can perform cluster-wide operations on the cluster, such as balancing, assigning or unassigning regions, or calling an explicit major compaction. This is an operations role.

    • A global admin with Create permissions can create or drop any table within HBase. This is more of a DBA-type role.

    In a production environment, it is likely that different users will have only one of Admin and Create permissions.

  • Namespace Admin - a namespace admin with Create permissions can create or drop tables within that namespace, and take and restore snapshots. A namespace admin with Admin permissions can perform operations such as splits or major compactions on tables within that namespace. Prior to CDH 5.4, only global admins could create namespaces. In CDH 5.4, any user with Namespace Create privileges can create namespaces.
  • Table Admins - A table admin can perform administrative operations only on that table. A table admin with Create permissions can create snapshots from that table or restore that table from a snapshot. A table admin with Admin permissions can perform operations such as splits or major compactions on that table.
  • Users - Users can read or write data, or both. Users can also execute coprocessor endpoints, if given Executable permissions.
Real-World Example of Access Levels.

This table shows some typical job descriptions at a hypothetical company and the permissions they might require in order to get their jobs done using HBase.
Job Title Scope Permissions Description
Senior Administrator Global Admin, Create Manages the cluster and gives access to Junior Administrators.
Junior Administrator Global Create Creates tables and gives access to Table Administrators.
Table Administrator Table Admin Maintains a table from an operations point of view.
Data Analyst Table Read Creates reports from HBase data.
Web Application Table Read, Write Puts data into HBase and uses HBase data to perform operations.

Further Reading

Enable HBase Authorization

HBase authorization is built on top of the Coprocessors framework, specifically AccessController Coprocessor.

Enable HBase Authorization Using Cloudera Manager

  1. Go to Clusters and select the HBase cluster.
  2. Select Configuration.
  3. Search for HBase Secure Authorization and select it.
  4. Search for HBase Service Advanced Configuration Snippet (Safety Valve) for hbase-site.xml and enter the following into it to enable hbase.security.exec.permission.checks. Without this option, all users will continue to have access to execute endpoint coprocessors. This option is not enabled when you enable HBase Secure Authorization for backward compatibility. 
    <property>
  <name>hbase.security.exec.permission.checks</name>
  <value>true</value>
</property>
  5. Optionally, search for and configure HBase Coprocessor Master Classes and HBase Coprocessor Region Classes.

Enable HBase Authorization Using the Command Line

To enable HBase authorization, add the following properties to the hbase-site.xml file on every HBase server host (Master or RegionServer):

<property>
     <name>hbase.security.authorization</name>
     <value>true</value>
</property>
<property>
  <name>hbase.security.exec.permission.checks</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.AccessController</value>
</property>

Configure Access Control Lists for Authorization

Now that HBase has the security coprocessor enabled, you can set ACLs using the HBase shell. Start the HBase shell as usual.

The commands that control ACLs take the following form. Group names are prefixed with the @ symbol.

hbase> grant <user> <permissions> [ @<namespace> [ <table>[ <column family>[ <column qualifier> ] ] ] ]   # grants permissions

hbase> revoke <user> [ @<namespace> [ <table> [ <column family> [ <column qualifier> ] ] ]  # revokes permissions

hbase> user_permission <table>                                                                            # displays existing permissions

In the above commands, fields encased in <> are variables, and fields in [] are optional. The permissions variable must consist of zero or more character from the set "RWCA".

  • R denotes read permissions, which is required to perform Get, Scan, or Exists calls in a given scope.
  • W denotes write permissions, which is required to perform Put, Delete, LockRow, UnlockRow, IncrementColumnValue, CheckAndDelete, CheckAndPut, Flush, or Compact in a given scope.
  • X denotes execute permissions, which is required to execute coprocessor endpoints.
  • C denotes create permissions, which is required to perform Create, Alter, or Drop in a given scope.
  • A denotes admin permissions, which is required to perform Enable, Disable, Snapshot, Restore, Clone, Split, MajorCompact, Grant, Revoke, and Shutdown in a given scope.

Access Control List Example Commands

grant 'user1', 'RWC'
grant 'user2', 'RW', 'tableA'
grant 'user3', 'C', '@my_namespace'

Be sure to review the information in Understanding HBase Access Levels to understand the implications of the different access levels.

Configuring the HBase Thrift Server Role

Minimum Required Role: Cluster Administrator (also provided by Full Administrator)

The Thrift Server role is not added by default when you install HBase, but it is required before you can use certain other features such as the Hue HBase browser. To add the Thrift Server role:
  1. Go to the HBase service.
  2. Click the Instances tab.
  3. Click the Add Role Instances button.
  4. Select the host(s) where you want to add the Thrift Server role (you only need one for Hue) and click Continue. The Thrift Server role should appear in the instances list for the HBase server.
  5. Select the Thrift Server role instance.
  6. Select Actions for Selected > Start.

Other HBase Security Topics