[
https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140723#comment-13140723
]
jirapos...@reviews.apache.org commented on HBASE-3025:
------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2041/
-----------------------------------------------------------
(Updated 2011-11-01 00:26:37.040678)
Review request for hbase.
Changes
-------
Updated patch addressing review comments:
* cleaned up audit logging of authorization decisions. Logging now occurs in
AccessController.requirePermission(), with a single audit log entry per
authorization decision.
* audit logging uses a more consistent format
* KeeperExceptions in ZKPermissionWatcher now trigger aborts where necessary,
instead of logging and dropping the exceptions.
Summary
-------
This patch implements access control list based authorization of HBase
operations. The patch depends on the currently posted patch for HBASE-2742
(secure RPC engine).
Key parts of the implementation are:
* AccessControlLists - encapsulates storage of permission grants in a metadata
table ("_acl_"). This differs from previous implementation where the ".META."
table was used to store permissions.
* AccessController -
- implements MasterObserver and RegionObserver, performing authorization
checks in each of the preXXX() hooks. If authorization fails, an
AccessDeniedException is thrown.
- implements AccessControllerProtocol as a coprocessor endpoint to provide
RPC methods for granting, revoking and listing permissions.
* ZKPermissionWatcher (and TableAuthManager) - synchronizes ACL entries and
updates throughout the cluster nodes using ZK. ACL entries are stored in
per-table znodes as /hbase/acl/tablename.
* Additional ruby shell scripts providing the "grant", "revoke" and
"user_permission" commands
* Support for a new OWNER attribute in HTableDescriptor. I could separate out
this change into a new JIRA for discussion, but I don't see it as currently
useful outside of security. Alternately, I could handle the OWNER attribute
completely in AccessController without changing HTD, but that would make
interaction via hbase shell a bit uglier.
This addresses bug HBASE-3025.
https://issues.apache.org/jira/browse/HBASE-3025
Diffs (updated)
-----
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlFilter.java
PRE-CREATION
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java
PRE-CREATION
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
PRE-CREATION
security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControllerProtocol.java
PRE-CREATION
security/src/main/java/org/apache/hadoop/hbase/security/access/Permission.java
PRE-CREATION
security/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java
PRE-CREATION
security/src/main/java/org/apache/hadoop/hbase/security/access/TablePermission.java
PRE-CREATION
security/src/main/java/org/apache/hadoop/hbase/security/access/UserPermission.java
PRE-CREATION
security/src/main/java/org/apache/hadoop/hbase/security/access/ZKPermissionWatcher.java
PRE-CREATION
security/src/test/java/org/apache/hadoop/hbase/security/access/SecureTestUtil.java
PRE-CREATION
security/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessControlFilter.java
PRE-CREATION
security/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java
PRE-CREATION
security/src/test/java/org/apache/hadoop/hbase/security/access/TestTablePermissions.java
PRE-CREATION
security/src/test/java/org/apache/hadoop/hbase/security/access/TestZKPermissionsWatcher.java
PRE-CREATION
src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java 99875b8
src/main/java/org/apache/hadoop/hbase/coprocessor/BaseRegionObserver.java
8a40762
src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java bb67e53
src/main/resources/hbase-default.xml 3785533
src/main/ruby/hbase.rb 4d27191
src/main/ruby/hbase/admin.rb 61e04d8
src/main/ruby/hbase/hbase.rb beb2450
src/main/ruby/hbase/security.rb PRE-CREATION
src/main/ruby/shell.rb 9a47600
src/main/ruby/shell/commands.rb a352c2e
src/main/ruby/shell/commands/grant.rb PRE-CREATION
src/main/ruby/shell/commands/revoke.rb PRE-CREATION
src/main/ruby/shell/commands/user_permission.rb PRE-CREATION
Diff: https://reviews.apache.org/r/2041/diff
Testing
-------
Thanks,
Gary
> Coprocessor based simple access control
> ---------------------------------------
>
> Key: HBASE-3025
> URL: https://issues.apache.org/jira/browse/HBASE-3025
> Project: HBase
> Issue Type: Sub-task
> Components: coprocessors
> Reporter: Andrew Purtell
> Attachments: HBASE-3025.1.patch, HBASE-3025.2011-02-01.patch
>
>
> Thanks for the clarification Jeff which reminds me to edit this issue.
> Goals of this issue
> # Client access to HBase is authenticated
> # User data is private unless access has been granted
> # Access to data can be granted at a table or per column family basis.
> Non-Goals of this issue
> The following items will be left out of the initial implementation for
> simplicity:
> # Row-level or per value (cell) This would require broader changes for
> storing the ACLs inline with rows. It's still a future goal, but would slow
> down the initial implementation considerably.
> # Push down of file ownership to HDFS While table ownership seems like a
> useful construct to start with (at least to lay the groundwork for future
> changes), making HBase act as table owners when interacting with HDFS would
> require more changes. In additional, while HDFS file ownership would make
> applying quotas easy, and possibly make bulk imports more straightforward,
> it's not clean it would offer a more secure setup. We'll leave this to
> evaluate in a later phase.
> # HBase managed "roles" as collections of permissions We will not model
> "roles" internally in HBase to begin with. We will instead allow group names
> to be granted permissions, which will allow some external modeling of roles
> via group memberships. Groups will be created and manipulated externally to
> HBase.
> While the assignment of permissions to roles and roles to users (or other
> roles) allows a great deal of flexibility in security policy, it would add
> complexity to the initial implementation.
> After the initial implementation, which will appear on this issue, we will
> evaluate the addition of role definitions internal to HBase in a new JIRA. In
> this scheme, administrators could assign permissions specifying HDFS groups,
> and additionally HBase roles. HBase roles would be created and manipulated
> internally to HBase, and would appear distinct from HDFS groups via some
> syntactic sugar. HBase role definitions will be allowed to reference other
> HBase role definitions.
--
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
