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

Andrew Purtell commented on HBASE-6222:
---------------------------------------

Some feedback from the Feb 28 HUG: Consider storing a reference to an ACL in 
the KV (logically in the ACL CF or inline as a tag) instead of the ACL itself. 
The ACL could be stored, versioned, in the _acl_ table. 

This is an interesting idea. It would address the case where the same ACL is 
stored in hundreds or thousands (or more) of values. We should save some space 
by writing the actual ACL only to one location. This also facilitates easy 
updates of the ACL, as a single atomic change, especially useful in the case 
where the initial mutations may have included an incorrect ACL. However, the 
tradeoff is two lookups instead of one for deciding what to do with every 
KeyValue: first, to the ACL CF to get the reference, if any, associated with 
the KV (but at least this is within the region); the second to a probably 
remote region of the _acl_ table to retrieve the ACL itself. It could be 
possible to cache the results of the ACL data lookups for a limited time, for 
however long a policy decision can be allowed to be out of date. If we have KV 
tags, the first lookup goes away but unfortunately the second remains, taking 
back some (most?) of the performance/latency gains we expect from inline 
storage.

I'm not sure the benefits outweigh the drawbacks.
                
> Add per-KeyValue Security
> -------------------------
>
>                 Key: HBASE-6222
>                 URL: https://issues.apache.org/jira/browse/HBASE-6222
>             Project: HBase
>          Issue Type: New Feature
>          Components: security
>    Affects Versions: 0.96.0, 0.98.0
>            Reporter: stack
>            Assignee: Andrew Purtell
>         Attachments: 6222-aclcf.patch, 6222.pdf, 
> cell-acls-kv-tags-not-for-review.zip, 
> HBaseCellRow-LevelSecurityDesignDoc.docx, HBaseCellRow-LevelSecurityPRD.docx
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to