You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2010/09/22 02:04:34 UTC
[jira] Created: (HBASE-3025) Coprocessor based RBAC policy engine
Coprocessor based RBAC policy engine
------------------------------------
Key: HBASE-3025
URL: https://issues.apache.org/jira/browse/HBASE-3025
Project: HBase
Issue Type: Sub-task
Reporter: Andrew Purtell
Assignee: Eugene Koontz
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-3025) Coprocessor based simple access
control
Posted by "Andrew Purtell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916825#action_12916825 ]
Andrew Purtell commented on HBASE-3025:
---------------------------------------
Regarding ZooKeeper, access is not controlled currently in a HBase installation. We are considering developing a Kerberos auth plugin for ZooKeeper, at which point ACLs can be set on znodes containing table permissions to prevent unprivileged users from subverting access control.
> 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 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-3025) Coprocessor based simple access
control
Posted by "Andrew Purtell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Purtell updated HBASE-3025:
----------------------------------
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 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.
was:
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.
Update terminology as suggested by comments on HBASE-3045.
> 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 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.
[jira] Commented: (HBASE-3025) Coprocessor based simple access
control
Posted by "Andrew Purtell (JIRA)" <ji...@apache.org>.
[ 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 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-3025) Coprocessor based RBAC policy engine
Posted by "Jeff Hammerbacher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915678#action_12915678 ]
Jeff Hammerbacher commented on HBASE-3025:
------------------------------------------
For those who don't know, RBAC stands for "Role-Based Access Control"
> Coprocessor based RBAC policy engine
> ------------------------------------
>
> Key: HBASE-3025
> URL: https://issues.apache.org/jira/browse/HBASE-3025
> Project: HBase
> Issue Type: Sub-task
> Reporter: Andrew Purtell
> Assignee: Eugene Koontz
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-3025) Coprocessor based simple access
control
Posted by "Andrew Purtell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916817#action_12916817 ]
Andrew Purtell commented on HBASE-3025:
---------------------------------------
Attached is a first cut at a coprocessor based access controller. It requires the patches pending for HBASE-2001 and HBASE-2002/HBASE-2321, and has additional dependency on secure Hadoop classes. Therefore we expect this to be developed in a feature branch until HBase compilation and operation on secure vs. nonsecure Hadoop flavors can be made seamless.
Package documentation will be forthcoming.
This access controller coprocessor should be associated with all tables as a system extension. (These are coprocessors listed in hbase-site.xml and loaded into the regionserver at an early time. See package docs in the patch on HBASE-2001 for more information pertaining to coprocessors specifically.)
Permissions for user tables are stored in a new {{acl:}} family in META. The access controller is active on META and user tables. When active on META, the access controller mirrors the contents of this family into a znode tree in zookeeper and updates the mirrored permissions information when values in {{acl:}} are added, changed, or deleted. When active on user tables, the access controller reads the permissions for its table from the appropriate znode, caches them, and sets a watch on the znode, updating the local cache whenever the znode data changes. The {{acl:}} family in META serves as persistent storage for access policy and as the canonical interface for defining access permissions. ZooKeeper serves to immediately and atomically propagate policy changes into the local permissions caches of all nodes in the cluster. For the typical user operation neither META nor ZooKeeper need be consulted when determining if a user has sufficient access privilege; up to date information will be found in the local cache.
A new shell command, {{grant}}, is added to support granting or revoking specific rights to tables. This is accomplished by puts or deletes into the new {{acl:}} family in META.
When tables are created the current (creating) user is given ownership of it. A table owner has full access to the table and can grant additional access. Ownership is tracked using an attribute of HTableDescriptor. Therefore currently a table must be disabled and modified to change ownership.
This patch also contains a small modification to HMaster that introduces the concept of _superuser_, a specially privileged principal defined via configuration variable, or by default the principal under which the Master or RegionServer processes are running. (Currently, for proper functioning of the cluster, the superuser must be the principal under which the processes are running.) Only the superuser can modify a table descriptor. This prevents a user from arbitrarily reassigning ownership and therefore bypassing access control. We may keep the superuser concept or replace it with an explicit ALTER permission. Perhaps even only the superuser should be allowed to enable and disable tables, though this patch does not at present prevent any user from taking those actions.
> 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 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-3025) Coprocessor based RBAC policy engine
Posted by "Eugene Koontz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913707#action_12913707 ]
Eugene Koontz commented on HBASE-3025:
--------------------------------------
s/to strong/too strong/
> Coprocessor based RBAC policy engine
> ------------------------------------
>
> Key: HBASE-3025
> URL: https://issues.apache.org/jira/browse/HBASE-3025
> Project: HBase
> Issue Type: Sub-task
> Reporter: Andrew Purtell
> Assignee: Eugene Koontz
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-3025) Coprocessor based simple access
control
Posted by "Andrew Purtell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Purtell updated HBASE-3025:
----------------------------------
Attachment: HBASE-3025.1.patch
> 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 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-3025) Coprocessor based simple access
control
Posted by "Andrew Purtell (JIRA)" <ji...@apache.org>.
[ 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.