HBase Browsing with doAs impersonation and Kerberos

25 March 2015 in Browsing - 6 minutes read

Hue comes with an HBase App that lets you create table, search for rows, read cell content… in just a few clicks. We are now glad to release the last missing piece of security (available in the upcoming Hue 3.8) for making the app production ready!

The HBase app talks to HBase through a proxy server (called Thrift Server V1) which forwards the commands to HBase. Because Hue stands between the proxy server and the actual user, the proxy server thinks that all the operations (e.g. create a table, scan some data…) are coming from the ‘hue’ user and not the actual Web user. This is obviously not very secure!

In order to secure the HBase app for real we need to:

  • make sure that the actual logged in user in Hue performs the operations with his privileges. This is the job of Impersonation.
  • make sure that the Hue server only sends these calls. This is the job of Kerberos strong authentication.

 

Note

We assume that you have installed an HBase Thrift Server in your cluster. If using Cloudera Manager, go to the list of instances of the HBase service and click on ‘Add Role Instances’ and select ‘HBase Thrift Server’.

 

Impersonation

HBase can now be configured to offer impersonation (with or without Kerberos). In our case this means that users can send commands to HBase through Hue without losing the fact that they will be ran under their own credentials (instead of the ‘hue’ user).

First, make sure you have this in your hbase-site.xml:

<property>

<name>hbase.thrift.support.proxyuser</name>

<value>true</value>

</property>

<property>

<name>hbase.regionserver.thrift.http</name>

<value>true</value>

</property>

 

Note

If using Cloudera Manager, this is done by typing ‘thrift’ in the configuration search of the HBase service and checking the first two results.

 

Then check in core-site.xml that HBase is authorized to impersonates someone:

<property>

<name>hadoop.proxyuser.hbase.hosts</name>

<value>*</value>

</property>

<property>

<name>hadoop.proxyuser.hbase.groups</name>

<value>*</value>

</property>

 

And finally check that Hue point to a local config directory of HBase specified in its hue.ini:

[hbase]

hbase_conf_dir=/etc/hbase/conf

 

Note

If you are using Cloudera Manager, you might want to select the HBase Thrift server in the Hue configuration and enter something like this in the Hue Service Advanced Configuration Snippet (Safety Valve) for hue_safety_valve.ini.

[hbase]

hbase_conf_dir={{HBASE_CONF_DIR}}

 

And that’s it, start the HBase Thrift Server and Hue and you are ready to go!

 

Security with Kerberos

Now that the Hue can send commands to the HBase Thrift Server and tell him to execute them as a certain user, we need to make sure that only Hue is allowed to do this. We are using Kerberos in order to strongly authenticate the users to the HBase service. In our case, the HBase Thrift server will accept commands only if they come from the Hue user only.

Make sure that HBase is configured with Kerberos and that you have this in the hbase-site.xml pointed by Hue:

<property>

<name>hbase.security.authentication</name>

<value>KERBEROS</value>

</property>

<property>

<name>hbase.thrift.kerberos.principal</name>

<value>hbase/_HOST@ENT.CLOUDERA.COM</value>

</property>

 

 

Note

If using Cloudera Manager or regular Thrift without impersonation, make sure to set the “HBase Thrift Authentication” hbase.thrift.security.qop must be set to one of the following:

  • auth-conf: authentication, integrity and confidentiality checking
  • auth-int: authentication and integrity checking
  • auth: authentication only

If using Cloudera Manager, go to “Hbase service > Configuration > Service-Wide / Security : HBase Thrift Authentication “ and select one of the following three options.

And similarly to above, make sure that the hue.ini points to a valid directory with hbase-site.xml:

[hbase]

hbase_conf_dir=/etc/hbase/conf

or

[hbase]

hbase_conf_dir={{HBASE_CONF_DIR}}

 

Note

If using Impersonation, make sure the HTTP/_HOST principal is in the keytab of for their HBase Thrift Server.

 

Restart HBase and Hue, and they should be all secured now!

 

Conclusion

You can now be sure that Hue users can only see or modify what they are allowed to at the HBase level. Hue guarantees that if a user cannot perform a certain operation in the HBase shell, it will exactly the same through Hue (Hue acts like a ‘view’ on top of HBase).

Note that HBase chose to support impersonation through HTTP Thrift, so regular Thrift won’t work when using impersonation. The previous Kerberos support also now makes sense since all the operations are not seeing as coming from the Hue user anymore! More work is on the way to make all these configuration steps only one click.

 

Now it is time to play with the table examples and open-up HBase to all your users!

 

 

As usual feel free to comment on the hue-user list or @gethue!

 

Note

This error means that the above ‘hadoop.proxyuser.hbase.hosts’ / ‘hadoop.proxyuser.hbase.groups’ properties are not correct:

Api Error: Error 500 User: hbase is not allowed to impersonate romain HTTP ERROR 500 Problem accessing /.

Reason: User: hbase is not allowed to impersonate bob Caused by:javax.servlet.ServletException:

User: hbase is not allowed to impersonate bob at org.apache.hadoop.hbase.thrift.ThriftHttpServlet.doPost(ThriftHttpServlet.java:117) at

Note

You might now see permission errors like below.

Api Error: org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient permissions (user=admin, scope=default, action=CREATE)...

This is because either:

  • you are using impersonation and your user ‘bob’ does not have enough HBase privileges
  • you are not using impersonation and the ‘hue’ user does not have enough HBase privileges

 

A quick way to fix this is to just give all the permissions. Obviously this is not recommended for a real setup, instead read more about HBase Access Control!

sudo -u hbase hbase shell

hbase(main):004:0> grant 'bob', 'RWC'

 

Note

If you are getting a “Api Error: TSocket read 0 bytes”, this is because Hue does not know that the Thrift Server is expecting Thrift HTTP. Double check that Hue points to an hbase-site.xml that contains the hbase.regionserver.thrift.http property set to true.

A temporary hack would be to insert this in the hue.ini:

[hbase]

use_doas=true

 

Note

“Api Error: maximum recursion depth exceeded” means that the HBase Thrift server is not running as an HTTP Kerberos service.

In the latest Hue 3.8 you should now just get a 401 error instead.

 

Note

buffered transport mode was not tested when using impersonation but might work.

 

Note

If you are getting this error:

Caused by: org.apache.hadoop.hbase.thrift.HttpAuthenticationException: Authorization header received from the client is empty.

You are very probably hitting https://issues.apache.org/jira/browse/HBASE-13069. Also make sure the HTTP/_HOST principal is in the keytab of for their HBase Thrift Server. Beware that as a follow-up you might get https://issues.apache.org/jira/browse/HBASE-14471.

There is also an issue with framed transport which is not supported yet. We recommend to use the buffered transport instead.

 


comments powered by Disqus

More recent stories

13 November 2019
Visually surfacing SQL information like Primary Keys, Foreign Keys, Views and Complex Types
Read More
31 October 2019
Missing some color? How to improve or add your own SQL syntax Highlighter
Read More
24 October 2019
How to create a HBase table on Kerberized Hadoop clusters
Read More