CDH5.4 Enabling Visibility Labels

[#1]

Instaling CDH5.4 with kerberos security gives me the opportunity to make grants to namespaces etc, but I want to enable visibility labels as well, which seem to be disabled by default.

Cloudera documentation only tells me this feature is experimental, but not how to enable it. Apache Book shows to add the proper coprocessors, but it also mentions the proper order of the coprocessors. 

As from: http://archive.cloudera.com/cdh5/cdh/5/hbase-1.0.0-cdh5.4.0/book.html#security.example.config

..I tried adding "org.apache.hadoop.hbase.security.visibility.VisibilityController" via the cloudera manager, but when reviewing the config changes, I see that the order is not correct, it's adding the Visibility Label in from of the (apparantly default AccessControler and TokenProvider, which is the incorrect order.

Any other way to enable this feature or to maintain the proper order? 

[#2 · Accepted solution]

You can use the CM -> HBase -> Configuration -> RegionServer Safety Valve (for hbase-site.xml) field to reorder the coprocessors via a manual XML override.

[#3]

I too am finding the visibility labels feature is disabled by default.  How do I go about enabling this feature?

[#4]

To be complete, yes you need to use the safety valves to get the correct order of the coprocessors. You also need to set the HFile version to 3, else Hbase won't start with these coprocessors. I find this last one odd, because Hbase 1.0 should use 3 by default, as per the docs.

Anyway, use the hbase documentation sample config as a sample of which setting you need where. http://archive.cloudera.com/cdh5/cdh/5/hbase-1.0.0-cdh5.4.0/book.html#security.example.config

[#5]

Thanks for closing the loop! We do not activate v3 HFiles in CDH5.4 to avoid breaking compatibility/adding additional work for users upgrading from an earlier CDH5 release: https://github.com/cloudera/hbase/commit/c9eb03bbf2c54b8e502feef89a59484bad987ff8

[#6]

---

@Harsh J wrote:
Thanks for closing the loop! We do not activate v3 HFiles in CDH5.4 to avoid breaking compatibility/adding additional work for users upgrading from an earlier CDH5 release: https://github.com/cloudera/hbase/commit/c9eb03bbf2c54b8e502feef89a59484bad987ff8

---

Thanks for your response.  I've only defined the VisibilityController as a coprocessor in my hbase-site.xml, so the ordering is not an issue for me.  Yet the visibility label feature is still disabled for me.  Anything else you can suggest for me to try?  I have set the hfile.format.version property to 3 as well.  I don't have the hbase.superuser property defined.  I will try setting it but don't know what else I can try.

Thanks again,

Barry

[#7]

Did you follow the guide at http://archive.cloudera.com/cdh5/cdh/5/hbase/book.html#_visibility_labels? What error do you specifically get in trying to use the feature?

Also, if you did change the HFile version, also ensure to run a major compaction on all tables to make the existing data migrate to it.

[#8]

ERROR: DISABLED: Visibility labels feature is not available.

I get that in hbase shell for commands like get_auths or add_labels.

So one thing I noticed is that when I was hand editing hbase-site.xml in
/etc/hbase/conf on all nodes, it had no effect(adding the
hfile.format.version and the coprocessors for master and region and yes I
did a restart after making the changes) However, when I added the
coprocessors through the cloudera UI, hbase didn't start up. I checked the
logs and sure enough it was complaining about hfile.format.version needing
to be set to 3. The problem now I'm having is that there is no
hfile.format.version property to set in the cloudera ui Configuration tab.
I'm assuming the clouder UI is modifying an hbase-site.xml file with these
values somwhere but obviously not in /etc/hbase/config.

[#9]

You can use the CM -> HBase -> Configuration -> RegionServer Safety Valve (for hbase-site.xml) to make the HFile V3 property setting change, since there's no direct UI field for it.

CM does separate client configs from server ones, to isolate and configure server specific items independently. This is better explained in the architecture docs at http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cm_intro_primer.html