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 Sat, 10 Nov 2012 19:33:12 GMT

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

Andrew Purtell commented on HBASE-6222:

[~v.himanshu] Thanks for the gracious comments.

bq. Currently, all the acl entries are stored in zk (limit of znode is 1 mb); will you be
using the same approach?

No. Pursuing an incremental approach, so, we keep per-table and per-CF ACLs implemented as-is
for now. Then add per cell ACLs as a third level of permissions checking. Per cell ACLs are
stored in the region alongside the data. It's an open question if having an ACL table will
still be necessary as things evolve.

bq. Its not clear how/where you are storing the acls at keyvalue level.

There are different approaches to doing this, will try two of them to establish the extent
of changes to core code required and performance differences:

1. Store per cell ACLs in tags in KV, using the approach to putting tags in KV that I described

2. Store per cell ACLs in a "shadow ACL column". Per cell ACLs are still associated with individual
KVs but in effect tag storage is moved external to the data KV, so no changes to the KeyValue
implementation are necessary, and stored in the same region. Will incur some additional cost
for querying tags but will not require intra cluster RPC.

3. Store per cell ACLs in the ACL table. Tag storage again is external to the data KV, and
now in a separate table. Will incur cost for querying tags and furthermore require intra cluster
RPC. Probably won't actually try this.

bq. You use acl table, or something else?

The ACL is stored "in" the KV (depends which impl option if that is physical or logical).
The table, row, family, qualifier, and timestamp of an in-KV permission are implicit -- those
of the KV's location. I do use TablePermission to represent ACLs at the KV level but only
to avoid some refactoring in the AccessController that would be outside the scope of a proof
of concept. Pardon if mentioning this detail was confusing.

bq. It doesn't make sense to attach an ACL on a Delete, because the KVs covered by the delete
will be ... deleted.
I don't completely agree with this but will not comment also unless I completely understand
your approach.

We treat ACLs on a KV as timestamped like the rest of the KV. An ACL in a new Put applies
only to that Put. It doesn't change the ACL of any previous Put. However, we require a Put
to have covering[1] permission -- so either table perms, CF perms, or perms in the most recent
visible existing value, if any, must allow the pending Put (or Append, or Increment, or any
mutation) in order for it to be applied. This is because the pending operation will replace
the visible value and its ACL, if it has one, for Gets and Scans that don't ask for more than
one version. If you actually want to change the ACL on a specific KV, you must Delete then
Put, if you have perms for that. On reads, a KV is visible to the InternalScanner if either
table perms, CF perms, or perms stored in the KV allow, similar to visibility labels in a
sense but with ACL semantics. The AccessControlFilter is extended to do that[2]. For Deletes,
_all_ visible prior versions covered by the Delete must allow the Delete, because a major
compaction could remove them if we allow the tombstone and it covers them, regardless of any
ACL they might contain. "Visible" here is defined as not covered by an already committed tombstone.
This allows simple and straightforward evolution of security policy over time without requiring
expensive updates[3].

So a Delete doesn't update ACLs. ACLs are bits of information to be stored with the KV. It's
meaningless to put an ACL on an op that stores nothing. And, an ACL on a Delete would not
grant that Delete permission to do something. It would be the union of per table, per CF,
and all ACLs on visible covered values that would grant (or not). Since we are only looking
at the most recent version of a KV, if any, except for Deletes, only Delete - and especially
DeleteColumn - can be potentially expensive to check. There is no free lunch but union-of-ACL
semantics helps: Granting appropriate per table or per CF perms to a user or group obviates
the need for KV ACL checking for that user or her groups, so we can early out and avoid going
to the store in that case.

[1] Maybe "covering" isn't quite the best term. Suggestions welcome.

[2] This changes AC semantics some. A user who doesn't have permissions to a CF or exact location
(column+qualifier) just won't get values back from a scan or get, as opposed to previous behavior
which would throw an AccessDeniedException if the user did not have required perms to the
CF at the CF level. I refactored TestAccessController to address this in a clean way.

[3] On the other hand GRANT and REVOKE commands could provide a convenient way to change per
KV ACLs too, since they are DDL not DML ops. We could consider enhancing the GRANT and REVOKE
command processing in the AccessController to replace all per KV ACLs covered by the action,
if they exist. A possible optimization is lazy updates via a timestamped log of recent GRANTs
and REVOKEs (but I just thought of that now so it's a superficial suggestion).
> 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
>            Assignee: Andrew Purtell
>         Attachments: 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