Community Articles
Find and share helpful community-sourced technical articles
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.
Labels (1)

This article will go over the concepts of security in an Hbase cluster. More specifically we will concentrate on ACL based security and how to apply at the different levels of granularity on an Hbase model.

From an overall security perspective and acces control list , or ACL, is a list of permissions associated with an object

ACLs focus on the access rules pattern.

ACL logic

Hbase access contol lists are granted on different levels of data abstractions and cover types of operations.

Hbase data layout

Before we go further let us clear out the hierarchical elements that compose the datastorage Hbase

10554-capture-decran-2016-12-19-a-155418.png

CELL : All values written to Hbase are stored in a what is know as a CELL. (Cell can also be refered to as KeyValue).

Cells are identified by a multidimensionnal key {row, column, qualifier, timestamp}. In the example above :

CELL => Rowkey1,CF1,Q11,TS1

COLUMN FAMILY : A column Family groups together arbitrary cells.

TABLE : All Cells belong to a Column family and are organized into a table.

NAMESPACE : Tables in turn belong to Namespaces. This can thought of as a database to table logic. With this in mind a table’s fully qualiefied name is

Table => Namespace :Table (the default namespace can be omitted)

Hbase scopes

Permissions are evaluated starting a the widest scope working to the narrowest scope.

10555-capture-decran-2016-12-20-a-091252.png

  • Global
  • Namespace
  • Table
  • Column Family (CF)
  • Column Qualifier (Q)
  • Cell

For example, a permission granted at a tabe dominates grants done at the column family level.

Permissions

Hbase can give granular access rights depending on each scope. Permissions are either zero or more letters from the set RWXCA.

  • Superuser : a special user that has unlimited access
  • Read(R) : Read right on the given scope
  • Write(W) : Write right on the given scope
  • Execute(X) : Coprocessor execution on the given scope
  • Create(C) : Can create and delete tables on the given scope
  • Admin(A) : Right to perform cluster admin operations, fro example granting rights

Combining access rights and scopes creates a complete matrix of access patterns and roles. In order to avoid complex conflicting rules it can often be useful to build access patterns from roles and reponsibilities up.

Role Responsibilites
Superuser Usually this role should be reserved solely to the Hbase user
Admin (A) Operationnal role : Performs cluster-wide operations like balancing, assigning regions

(C) DBA type role, creates and drops tables and namespaces

Namespace Admin (A) : Manages a specific namespaces from an operations perspective can take snapshots and splits etc..

(C) From a DBA perspective can create tables and give access

Table Admin (A) Operationnal role can manage splits,compactions ..

(C) can create snpashots, restore a table etc..

Power User (RWX) can use the table by writing or reading data and possibly use coprocessors.
Consumer (R) User can only read and consume data

Some actions need a mix of these permissions to be performed

  • CheckAndPut / CheckAndDelete : thee actions need RW permissions
  • Increment/Append : only require W permissions

A full complete list of the acl matrix can be found here : http://hbase.apache.org/book.html#appendix_acl_matrix

Setting up

In order to setup Hbase ACLs you will need to modify the Hbase-site.xml with the following properties

<property>
  <name>hbase.coprocessor.region.classes</name>   <value>org.apache.hadoop.hbase.security.access.AccessController, 
org.apache.hadoop.hbase.security.token.TokenProvider</value>  
</property>  
<property>
  <name>hbase.coprocessor.master.classes</name> 
<value>org.apache.hadoop.hbase.security.access.AccessController</value>  </property>
<property>  
  <name>hbase.coprocessor.regionserver.classes</name>   <value>org.apache.hadoop.hbase.security.access.AccessController</value>  </property>  
<property>  
  <name>hbase.security.exec.permission.checks</name>  <value>true</value>  
</property>

In Ambari this is much easier just enable security and Ambari will automatically set all these configurations for you.

10557-capture-decran-2016-12-20-a-160038.png

10558-capture-decran-2016-12-19-a-115623.png

Applying ACLs

Now that we have restarted our Hbase cluster and set up the ACL feature we can start setting up rules.

For simplitcity purposes we will use 2 users : Hbase and testuser.

Hbase is the superuser for our cluster and will let us set the rights accordingly.

Namespace

As the Hbase use we create an ‘acl’ namespace

hbase(main):001:10> create_namespace ‘acl’
0 row(s)in 0.3180 seconds

As testuser we will create a table in this new namespace

hbase(main):001:0>
create 'atest','cf'ERROR:
org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient
permissions (user=testuser, scope=default,
params=[namespace=default,table=default:atest,family=cf],action=CREATE)

We are not allowed to create a tabe in this namespace. Super user Hbase will give the rights to testuser.

hbase(main):001:10> grant 'testuser','C','@acl'0
row(s) in 0.3360 seconds

We can now run the previous command as the testuser

hbase(main):002:0> create 'atest','cf'0
row(s) in 2.3360 seconds

We will now open this table to another user testuser2

hbase(main):002:0> grant 'testuser2','R','@acl'ERROR:
org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient permissions
(user=testuser, scope=acl, params=[namespace=acl],action=ADMIN)

Notice we can’t grant rights to other users as we are missing Admin permissions

We can fix this with our Hbase super user

hbase(main):002:20> grant 'testuser','A','@acl'0
row(s) in 0.460 seconds
2,184 Views
Don't have an account?
Coming from Hortonworks? Activate your account here
Version history
Revision #:
2 of 2
Last update:
‎08-17-2019 07:12 AM
Updated by:
 
Contributors
Top Kudoed Authors