[
https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-3025:
----------------------------------
Summary: Coprocessor based simple access control (was: Coprocessor
based RBAC policy engine)
Description:
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 group definitions internal to HBase in a new JIRA. In
this scheme, administrators could assign permissions specifying HDFS groups,
and additionally HBase groups. HBase groups would be created and manipulated
internally to HBase, and would appear distinct from HDFS groups via some
syntactic sugar. HBase group definitions will be allowed to reference other
HBase group definitions.
> 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
>
> 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 group definitions internal to HBase in a new JIRA.
> In this scheme, administrators could assign permissions specifying HDFS
> groups, and additionally HBase groups. HBase groups would be created and
> manipulated internally to HBase, and would appear distinct from HDFS groups
> via some syntactic sugar. HBase group definitions will be allowed to
> reference other HBase group definitions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
