[jira] [Commented] (HBASE-6222) Add per-KeyValue Security

["stack (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13393450#comment-13393450 ] 

stack commented on HBASE-6222:
------------------------------

@Lars When you say "...I thought it might be good to have the option to add "tags" to each KV", what would a tag look like?  A bit set?  Or some name/values within the KV?

I like Jon's suggestion that HBASE-2893 could be less onerous if we implemented Locality groups (the meta-cf would be co-mingled w/ the data its meta for).

bq. They delta encode their keys (including the visiblity tags) like we do in 0.94.

Should we turn the above on as default?

bq. As a straw man, a core-changing HBase version that modified KV's wouldn't necessarily incur more space – we could use a new KeyValue.Type (TaggedPut?) that had visibility settings, and use the old Put type that used the default tags.

KVs are also versioned so we should be able to up the version and add new in-key facility (A while back I messed w/ doing this adding a sequenceid beside the timestamp... I did it as "conditional code" rather than as subclass which for sure compounded the complexity of the already-complex KeyValue -- unfortunately, hopefully there is a better route -- but it seemed possible making different KV types float in same scanner merge....).  If we add a ColumnVisibility-like expression into the KV, we'd have to update Comparators to exclude this portion from inclusion in sort.

On making KV an Interface, that'd be cool.  Todd had a go at it a while back but the ripple turned into an avalanche of code changes IIRC so he suggested we do it piecemeal.  It'd be sweet though.

+1 on Andrew's proposal first.  We need a driver?

On faithful mimicking of Accumulo's implementation, that makes sense in the absence of an actual customer who needs this stuff (Jon? You have one?)?  Maybe the Accumulo implementation is far from what is wanted -- these 'expression's are passed in the clear -- and a superior implementation might not be that much of a stretch? 
                
> Add per-KeyValue Security
> -------------------------
>
>                 Key: HBASE-6222
>                 URL: https://issues.apache.org/jira/browse/HBASE-6222
>             Project: HBase
>          Issue Type: New Feature
>          Components: security
>            Reporter: stack
>
> Saw an interesting article: http://www.fiercegovernmentit.com/story/sasc-accumulo-language-pro-open-source-say-proponents/2012-06-14
> "The  Senate Armed Services Committee version of the fiscal 2013 national defense authorization act (S. 3254) would require DoD agencies to foreswear the Accumulo NoSQL database after Sept. 30, 2013, unless the DoD CIO certifies that there exists either no viable commercial open source database with security features comparable to [Accumulo] (such as the HBase or Cassandra databases)..."
> Not sure what a 'commercial open source database' is, and I'm not sure whats going on in the article, but tra-la-la'ing, if we had per-KeyValue 'security' like Accumulo's, we might put ourselves in the running for federal contributions?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira