hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6222) Add per-KeyValue Security
Date Mon, 04 Mar 2013 09:19:13 GMT

    [ 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
> 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

View raw message