I'm facing strange issues with Ranger/HBase policies :
Basically, I would like to authorize READ access to a set of tables to a single group of users (seems pretty straightforward...).
My tables belong to the same namespace and have a common prefix in their name, so I first wondered how to express this in my ranger policy ...
First of all, I found opposite information about wildcards support in hbase table field : https://community.hortonworks.com/questions/77467/hbase-policy-with-ranger.html post mentions that this is not supported by ranger, whereas https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+0.5+-+User+Guide#ApacheRanger0.5-Us... documentation says this is possible...
I decided to give it a try : I tried to set "namespace:prefix*" as the "HBase table" field I then executed hbase shell from one user belonging to the target group but could not perform "scan" or "count" operations on my tables : got "Insufficient permissions for user" error... Then I played around with my policy several times but couldn't understand resulting behavior ! In the end, I set "namespace:*" as hbase table in the policy, but strangely, I get "Insufficient permissions for user" error for all the tables except one !!! I am pretty sure that I explicitely set up the full name of this table in my policy at some point during my tests ("namespace:fulltablename"), but changed to something else afterward, so I wonder if there could be some "caching" of the policies that could explain why the latest version of the policy is not applied ?
I'm not familiar with ranger, but I took a look at audit results in HDFS : Weird situation (again) as /ranger/audit/hbaseMaster/ does not contain any folder for current day ?!?
It is the same in /ranger/audit/hbaseRegional/...I'm a bit confused about this : why my current tests dont generate anything in ranger audit files ???
Does anyone have any clue about this or could shed light on audit mechanism so that I can debug the situation ?
Thanks for your help
In fact the problem was not linked to ranger but to underlying definition of our groups & users.
I can confirm that following syntaxes work fine :
Hi @Sebastien Chausson: Wildcard support is there for policy resources and should work fine, like you yourself have confirmed.
As for Audit, Ranger has a neat Audit UI (part of Ranger UI) which makes it easier and simpler to look at audit results. From top global menu, select Audit and then click on Access tab to get Audits resulting from trying to access resources. There is a search box using which you can search on service type, user, resource, service name, operation etc..