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-3025) Coprocessor based simple access control
Date Fri, 01 Oct 2010 08:03:34 GMT

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

Andrew Purtell commented on HBASE-3025:

Regarding the Master, more work needs to be done to disallow a user from taking administrative
actions on other user's tables, such as enable/disable/drop. We only made one modification
to the Master as a suggestion for one design option. With coprocessors its easy to encapsulate
access control related changes to regionserver function. However, the coprocessor framework
is a regionserver only feature. We don't as of yet have a similar extension framework for
the Master. Therefore we need to consider one, or follow through with defining a concept of
ownership and restrictions on administrative actions that can be taken by owners vs non-owners.

> Coprocessor based simple access control
> ---------------------------------------
>                 Key: HBASE-3025
>                 URL: https://issues.apache.org/jira/browse/HBASE-3025
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Andrew Purtell
>            Assignee: Eugene Koontz
>         Attachments: HBASE-3025.1.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
> # 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
> # 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.
You can reply to this email to add a comment to the issue online.

View raw message