HBase 权限控制

HBase的权限管理依赖协协处理器。所以我们需要配置hbase.security.authorization=true，以及hbase.coprocessor.master.classes和hbase.coprocessor.master.classes使其包含org.apache.hadoop.hbase.security. access.AccessController来提供安全管控能力。所以需要设置下面参数：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

<property>        <name> hbase.superuser </name>        <value> hbase </value> </property> <property>      <name> hbase.coprocessor.region.classes </name>      <value> org.apache.hadoop.hbase.security.access.AccessController </value>    </property> <property>      <name> hbase.coprocessor.master.classes </name>      <value> org.apache.hadoop.hbase.security.access.AccessController </value> </property> <property>      <name> hbase.rpc.engine </name>      <value> org.apache.hadoop.hbase.ipc.SecureRpcEngine </value> </property> <property>        <name> hbase.security.authorization </name>        <value> true </value> </property>

HBase提供的五个权限标识符：RWXCA,分别对应着READ('R'), WRITE('W'), EXEC('X'),CREATE('C'), ADMIN('A')
HBase提供的安全管控级别包括：
Superuser：拥有所有权限的超级管理员用户。通过hbase.superuser参数配置
Global：全局权限可以作用在集群所有的表上。
Namespace ：命名空间级。
Table：表级。
ColumnFamily：列簇级权限。
Cell：单元级。
和关系数据库一样，权限的授予和回收都使用grant和revoke，但格式有所不同。grant语法格式：
grant user permissions table column_family column_qualifier
例如，给用户hive分配对表member有读写的权限, 在启用了hbase.security.authorization之后，默认每个用户只能访问当前的表。而之前创建的member表的属主是HBase，其他用户对其没有访问权限。此时我们通过hive来查找：

1 2 3

# sudo -u hive hbase shell > scan 'member' ERROR : org . apache . hadoop . hbase . security . AccessDeniedException : Insufficient permissions ( table = member , action = READ )

在HBase中赋值权限：

1 2	> grant 'hive' , 'RW' , 'member' 0 row ( s ) in 0.4660 seconds

然后通过user_permission来查看权限

1 2 3

> user_permission User     Table , Family , Qualifier : Permission Hive   member , , : [ Permission : actions = READ , WRITE ]

再在hive中进行查询，此时hive用户已经可以访问。

1 2 3 4

> scan 'member' ROW     COLUMN + CELL Elvis     column = address : city , timestamp = 1425891057211 , value = Beijing ……

收回权限revoke的语法格式
revoke user table column family column qualifier
收回hive用户在表member上的权限

1 2	> revoke 'hive' , 'member' 0 row ( s ) in 0.1860 seconds

更多的信息请参见：
http://www.cloudera.com/content/cloudera/en/documentation/core/v5-2-x/topics/cdh_sg_hbase_authorization.html

Posted in  BigData,  HBase|Hive,  NoSQL.

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. for Cell-level authorization was added as an experimental feature in CDH 5.2 and is still considered experimental.

• Understanding HBase Access Levels
• Enable HBase Authorization
• Configure Access Control Lists for Authorization

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 propertyhbase.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 appendor 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 Createpermissions.

  Warning:

  In the current implementation, a Global Admin with Admin permission can grant himself Read and Writepermissions on a table and gain access to that table's data. For this reason, only grant Global Adminpermissions 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.2.1. It is not fixed in CDH 4.x or CDH 5.1.x.

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

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

  Warning:

  In the current implementation, a Global Admin with Admin permission can grant himself Read and Writepermissions on a table and gain access to that table's data. For this reason, only grant Global Adminpermissions 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 newer, as well as CDH 5.2.1. It is not fixed in CDH 4.x or CDH 5.1.x.

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

Important:

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

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	Access, 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	Access	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

• Access Control Matrix
• Security - Apache HBase Reference Guide

Enable HBase Authorization

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

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

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.

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.

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 are of the form of:

grant <user> <permissions>[ <table>[ <column family>[ <column qualifier> ] ] ]    #grants permissions
revoke <user> <permissions> [ <table> [ <column family> [ <column qualifier> ] ] ]   # revokes permissions 
user_permission <table>  # displays existing permissions

In the above commands, fields encased in <> are variables, and fields in [] are optional. The permissionsvariable 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.

For example:

grant 'user1', 'RWC'
grant 'user2', 'RW', 'tableA'

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