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 might need superuser access 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.

    Warning:

  In the current implementation, a Global Admin with Admin permission can grant himself Read and Write permissions on a table and gain access to that table's data. For this reason, only grant Global Admin permissions to trusted user who actually need them.

  Also be aware that a Global Admin with Create permission can perform a Put operation on the ACL table, simulating a grant or revoke and circumventing the authorization check for Global Admin permissions. This issue (but not the first one) is fixed in CDH 5.3 and higher, as well as CDH 5.2.1.

  Due to these issues, be cautious with granting Global Admin privileges.

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

  Important:

If you are using Kerberos principal names when setting ACLs for users, Hadoop uses only the first part (short) of the Kerberos principal when converting it to the username. Hence, for the principal ann/fully.qualified.domain.name@YOUR-REALM.COM, HBase ACLs should only be set for user ann.

The following table shows some typical job descriptions at a hypothetical company and the permissions they might require to get their jobs done using HBase.

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

  Note: Once the Access Controller coprocessor is enabled, any user who uses the HBase shell will be subject to access control. Access control will also be in effect for native (Java API) client access to HBase.

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

  Important:

The host running the shell must be configured with a keytab file as described in Configuring Kerberos Authentication for HBase.

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> <permissions> [ @<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.

hbase.security.exec.permission.checks => true (the default value is false)
hbase.security.access.early_out => false (the default value is true)
hfile.format.version => 3 (the default value is 2)

grant 'Employee', { 'employe.name' => 'R' }, { COLUMNS => [ 'pd' ], FILTER => "(PrefixFilter ('T'))" }