Secure Client Access to HBase
Newer releases of HBase (>= 0.92) support optional SASL authentication of clients.
This describes how to set up HBase and HBase clients for connection to secure HBase resources.
HBase must have been built using the new maven profile for secure Hadoop/HBase: -P security. Secure Hadoop dependent classes are separated under a pseudo-module in the security/ directory and are only included if built with the secure Hadoop profile.
You need to have a working Kerberos KDC.
A HBase configured for secure client access is expected to be running
on top of a secured HDFS cluster. HBase must be able to authenticate
to HDFS services. HBase needs Kerberos credentials to interact with
the Kerberos-enabled HDFS daemons. Authenticating a service should be
done using a keytab file. The procedure for creating keytabs for HBase
service is the same as for creating keytabs for Hadoop. Those steps
are omitted here. Copy the resulting keytab files to wherever HBase
Master and RegionServer processes are deployed and make them readable
only to the user account under which the HBase daemons will run.
A Kerberos principal has three parts, with the form
username/fully.qualified.domain.name@YOUR-REALM.COM. We
recommend using hbase as the username portion.
The following is an example of the configuration properties for
Kerberos operation that must be added to the
hbase-site.xml file on every server machine in the
cluster. Required for even the most basic interactions with a
secure Hadoop configuration, independent of HBase security.
hbase.regionserver.kerberos.principal
hbase/_HOST@YOUR-REALM.COM
hbase.regionserver.keytab.file
/etc/hbase/conf/keytab.krb5
hbase.master.kerberos.principal
hbase/_HOST@YOUR-REALM.COM
hbase.master.keytab.file
/etc/hbase/conf/keytab.krb5
]]>
Each HBase client user should also be given a Kerberos principal. This
principal should have a password assigned to it (as opposed to a
keytab file). The client principal's maxrenewlife should
be set so that it can be renewed enough times for the HBase client
process to complete. For example, if a user runs a long-running HBase
client process that takes at most 3 days, we might create this user's
principal within kadmin with: addprinc -maxrenewlife
3days
Long running daemons with indefinite lifetimes that require client
access to HBase can instead be configured to log in from a keytab. For
each host running such daemons, create a keytab with
kadmin or kadmin.local. The procedure for
creating keytabs for HBase service is the same as for creating
keytabs for Hadoop. Those steps are omitted here. Copy the resulting
keytab files to where the client daemon will execute and make them
readable only to the user account under which the daemon will run.
Server-side Configuration for Secure Operation
Add the following to the hbase-site.xml file on every server machine in the cluster:
hbase.security.authentication
kerberos
hbase.security.authorization
true
hbase.rpc.engine
org.apache.hadoop.hbase.ipc.SecureRpcEngine
hbase.coprocessor.region.classes
org.apache.hadoop.hbase.security.token.TokenProvider
]]>
A full shutdown and restart of HBase service is required when deploying
these configuration changes.
Client-side Configuration for Secure Operation
Add the following to the hbase-site.xml file on every client:
hbase.security.authentication
kerberos
hbase.rpc.engine
org.apache.hadoop.hbase.ipc.SecureRpcEngine
]]>
The client environment must be logged in to Kerberos from KDC or
keytab via the kinit command before communication with
the HBase cluster will be possible.
Be advised that if the hbase.security.authentication
and hbase.rpc.engine properties in the client- and
server-side site files do not match, the client will not be able to
communicate with the cluster.
Once HBase is configured for secure RPC it is possible to optionally
configure encrypted communication. To do so, add the following to the
hbase-site.xml file on every client:
hbase.rpc.protection
privacy
]]>
This configuration property can also be set on a per connection basis.
Set it in the Configuration supplied to
HTable:
Configuration conf = HBaseConfiguration.create();
conf.set("hbase.rpc.protection", "privacy");
HTable table = new HTable(conf, tablename);
Expect a ~10% performance penalty for encrypted communication.
Client-side Configuration for Secure Operation - Thrift Gateway
Add the following to the hbase-site.xml file for every Thrift gateway:
hbase.thrift.keytab.file
/etc/hbase/conf/hbase.keytab
hbase.thrift.kerberos.principal
$USER/_HOST@HADOOP.LOCALDOMAIN
]]>
Substitute the appropriate credential and keytab for $USER and $KEYTAB
respectively.
The Thrift gateway will authenticate with HBase using the supplied
credential. No authentication will be performed by the Thrift gateway
itself. All client access via the Thrift gateway will use the Thrift
gateway's credential and have its privilege.
Client-side Configuration for Secure Operation - REST Gateway
Add the following to the hbase-site.xml file for every REST gateway:
hbase.rest.keytab.file
$KEYTAB
hbase.rest.kerberos.principal
$USER/_HOST@HADOOP.LOCALDOMAIN
]]>
Substitute the appropriate credential and keytab for $USER and $KEYTAB
respectively.
The REST gateway will authenticate with HBase using the supplied
credential. No authentication will be performed by the REST gateway
itself. All client access via the REST gateway will use the REST
gateway's credential and have its privilege.
It should be possible for clients to authenticate with the HBase
cluster through the REST gateway in a pass-through manner via SPEGNO
HTTP authentication. This is future work.
Access Control
Newer releases of HBase (>= 0.92) support optional access control
list (ACL-) based protection of resources on a column family and/or
table basis.
This describes how to set up Secure HBase for access control, with an
example of granting and revoking user permission on table resources
provided.
You must configure HBase for secure operation. Refer to the section
"Secure Client Access to HBase" and complete all of the steps described
there.
You must also configure ZooKeeper for secure operation. Changes to ACLs
are synchronized throughout the cluster using ZooKeeper. Secure
authentication to ZooKeeper must be enabled or otherwise it will be
possible to subvert HBase access control via direct client access to
ZooKeeper. Refer to the section on secure ZooKeeper configuration and
complete all of the steps described there.
With Secure RPC and Access Control enabled, client access to HBase is
authenticated and user data is private unless access has been
explicitly granted. Access to data can be granted at a table or per
column family basis.
However, the following items have been left out of the initial
implementation for simplicity:
Row-level or per value (cell): This would require broader changes for storing the ACLs inline with rows. It is a future goal.
Push down of file ownership to HDFS: HBase is not designed for the case where files may have different permissions than the HBase system principal. Pushing file ownership down into HDFS would necessitate changes to core code. Also, while HDFS file ownership would make applying quotas easy, and possibly make bulk imports more straightforward, it is not clear that it would offer a more secure setup.
HBase managed "roles" as collections of permissions: We will not model "roles" internally in HBase to begin with. We instead allow group names to be granted permissions, which allows external modeling of roles via group membership. Groups are created and manipulated externally to HBase, via the Hadoop group mapping service.
Access control mechanisms are mature and fairly standardized in the relational database world. The HBase implementation approximates current convention, but HBase has a simpler feature set than relational databases, especially in terms of client operations. We don't distinguish between an insert (new record) and update (of existing record), for example, as both collapse down into a Put. Accordingly, the important operations condense to four permissions: READ, WRITE, CREATE, and ADMIN.
Operation To Permission Mapping
Permission
Operation
Read
Get
Exists
Scan
Write
Put
Delete
Lock/UnlockRow
IncrementColumnValue
CheckAndDelete/Put
Flush
Compact
Create
Create
Alter
Drop
Admin
Enable/Disable
Split
Major Compact
Grant
Revoke
Shutdown
Permissions can be granted in any of the following scopes, though
CREATE and ADMIN permissions are effective only at table scope.
Table
Read: User can read from any column family in table
Write: User can write to any column family in table
Create: User can alter table attributes; add, alter, or drop column families; and drop the table.
Admin: User can alter table attributes; add, alter, or drop column families; and enable, disable, or drop the table. User can also trigger region (re)assignments or relocation.
Column Family
Read: User can read from the column family
Write: User can write to the column family
There is also an implicit global scope for the superuser.
The superuser is a principal, specified in the HBase site configuration
file, that has equivalent access to HBase as the 'root' user would on a
UNIX derived system. Normally this is the principal that the HBase
processes themselves authenticate as. Although future versions of HBase
Access Control may support multiple superusers, the superuser privilege
will always include the principal used to run the HMaster process. Only
the superuser is allowed to create tables, switch the balancer on or
off, or take other actions with global consequence. Furthermore, the
superuser has an implicit grant of all permissions to all resources.
Tables have a new metadata attribute: OWNER, the user principal who owns
the table. By default this will be set to the user principal who creates
the table, though it may be changed at table creation time or during an
alter operation by setting or changing the OWNER table attribute. Only a
single user principal can own a table at a given time. A table owner will
have all permissions over a given table.
Server-side Configuration for Access Control
Enable the AccessController coprocessor in the cluster configuration
and restart HBase. The restart can be a rolling one. Complete the
restart of all Master and RegionServer processes before setting up
ACLs.
To enable the AccessController, modify the hbase-site.xml file on every server machine in the cluster to look like:
hbase.coprocessor.master.classes
org.apache.hadoop.hbase.security.access.AccessController
hbase.coprocessor.region.classes
org.apache.hadoop.hbase.security.token.TokenProvider,
org.apache.hadoop.hbase.security.access.AccessController
]]>
Shell Enhancements for Access Control
The HBase shell has been extended to provide simple commands for editing and updating user permissions. The following commands have been added for access control list management:
Grant
grant <user> <permissions> <table> [ <column family> [ <column qualifier> ] ]
<permissions> is zero or more letters from the set "RWCA": READ('R'), WRITE('W'), CREATE('C'), ADMIN('A').
Note: Grants and revocations of individual permissions on a resource are both accomplished using the grant command. A separate revoke command is also provided by the shell, but this is for fast revocation of all of a user's access rights to a given resource only.
Revoke
revoke <user> <table> [ <column family> [ <column qualifier> ] ]
Alter
The alter command has been extended to allow ownership assignment:
alter 'tablename', {OWNER => 'username'}
User Permission
The user_permission command shows all access permissions for the current user for a given table:
user_permission