Configuring HBase Authorization | 6.3.x (2023)

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 anyprincipals 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 aspecific 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 towrite 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 orincremented 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 accesslevels 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 isrequired 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 superuseraccess 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, anadmin 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 callingan explicit major compaction. This is an operations role.

    (Video) Apache HBase Connector: Feature Rich and Efficient Access to HBase through Spark SQL - Weiqing Yang

  • 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 namespaceadmin 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, anyuser with Namespace Create privileges can create namespaces.
• Table Admins - A table admin can perform administrative operations only on that table. A table admin with Createpermissions 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 ormajor compactions on that table.
• Users - Users can read or write data, or both. Users can also execute coprocessor endpoints, if given Executablepermissions.

Further Reading

• Access Control Matrix
• Security - Apache HBase Reference Guide

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

Configure Cell_Level Access Control Lists

If you wish to enable cell-level ACLs for HBase, then you must modify the default values for the following properties:

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)

Unless you modify the default properties as specified (or via the service-wide HBase Service Advanced Configuration Snippet (Safety Valve) forhbase-site.xml, which requires a service restart), then cell level ACLs will not work.

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