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] [Comment Edited] (HBASE-6222) Add per-KeyValue Security
Date Tue, 19 Jun 2012 22:35:43 GMT

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

Andrew Purtell edited comment on HBASE-6222 at 6/19/12 10:34 PM:
-----------------------------------------------------------------

Correct me if I'm wrong but given all of the above discussion therefore the scope of changes
necessary are:

* Add a facility for storing string tags with each KV. Will need to do this for both puts
and deletes.

* Update the KV comparators to take into account tags in the sort order, if present.

* Add a coprocessor (perhaps another implementation of Constraint) that:
** Implements a visibility filter that evaluates for each KV if the current set of user-supplied
labels intersects with allowed labels according to visibility predicates stored in the KV,
if any, and emits (or not);
** Unpacks labels added by the client via our generic op attributes facility and adds them
to KVs in a mutator op or programs the visibility filter on a Get or Scan;
** Always adds the visibility filter to Get and Scan operations, wrapping any other supplied
filter with FilterList(MUST_PASS_ALL) and the visibility filter on the RHS so we can let the
other filters reduce the number of visibility evaluations necessary.

* Shell support
** Add setuaths and getauths equivalent shell commands
** Extend the other shell ops with sugar for adding labels as a working example of how to
do it via the Java client

And the constraints on implementation are:

* Tag storage optimized out if no tags present

* Compartmentalized changes

* The mechanism for adding, reading, removing, and modifying tags in the KV should be generic

Does that about sum it up?

@Laxman: Such a Constraint-based coprocessor as described would be orthogonal to AccessController.
One could use both at the same time independently, or they could be unified at some point.


@Lars
{quote}
bq. @Andy: Compartmentalized changes

Agreed, we add a new type and handle that case separately. Though the majority of the code
is shared, the new type would trigger the extraction of the tags if called for (which I assume
would be done lazily).
{quote}

So one new type that causes us to extract tags then recurse on the actual wrapped op? And
we extend all necessary internal method signatures to carry tags around? Edit: By that I mean
a pointer to where they are serialized in byte[] if doing it lazily as you suggest.

Edit: Removed one line of language where I went off in the weeds a bit.
                
      was (Author: apurtell):
    Correct me if I'm wrong but given all of the above discussion therefore the scope of changes
necessary are:

* Add a facility for storing string tags with each KV. Will need to do this for both puts
and deletes.

* Update the KV comparators to take into account tags in the sort order, if present.

* Add a coprocessor (perhaps another implementation of Constraint) that:
** Implements a visibility filter that evaluates for each KV if the current set of user-supplied
labels intersects with allowed labels according to visibility predicates stored in the KV,
if any, and emits (or not);
** Unpacks labels added by the client via our generic op attributes facility and adds them
to KVs in a mutator op or programs the visibility filter on a Get or Scan;
** Always adds the visibility filter to Get and Scan operations, wrapping any other supplied
filter with FilterList(MUST_PASS_ALL) and the visibility filter on the RHS so we can let the
other filters reduce the number of visibility evaluations necessary.

* Shell support
** Add setuaths and getauths equivalent shell commands
** Extend the other shell ops with sugar for adding labels as a working example of how to
do it via the Java client
** Table create command sugar that adds the Constraint specification without a lot of user
typing necessary?

And the constraints on implementation are:

* Tag storage optimized out if no tags present

* Compartmentalized changes

* The mechanism for adding, reading, removing, and modifying tags in the KV should be generic

Does that about sum it up?

@Laxman: Such a Constraint-based coprocessor as described would be orthogonal to AccessController.
One could use both at the same time independently, or they could be unified at some point.


@Lars
{quote}
bq. @Andy: Compartmentalized changes

Agreed, we add a new type and handle that case separately. Though the majority of the code
is shared, the new type would trigger the extraction of the tags if called for (which I assume
would be done lazily).
{quote}

So one new type that causes us to extract tags then recurse on the actual wrapped op? And
we extend all necessary internal method signatures to carry tags around? Edit: By that I mean
a pointer to where they are serialized in byte[] if doing it lazily as you suggest.
                  
> 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

        

Mime
View raw message