[jira] [Updated] (HBASE-3025) Coprocessor based simple access control
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling updated HBASE-3025: - Status: Patch Available (was: Open) 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 Priority: Critical Fix For: 0.92.0 Attachments: HBASE-3025.1.patch, HBASE-3025_5.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
[jira] [Updated] (HBASE-3025) Coprocessor based simple access control
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling updated HBASE-3025: - Attachment: HBASE-3025_6.patch Attaching final patch. Only change is removal of a small amount of duplicated code in previous patch from admin.rb. 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 Priority: Critical Fix For: 0.92.0 Attachments: HBASE-3025.1.patch, HBASE-3025_5.patch, HBASE-3025_6.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
[jira] [Updated] (HBASE-3025) Coprocessor based simple access control
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling updated HBASE-3025: - Resolution: Fixed Release Note: This is part of an overall implementation of security features for HBase. This issue adds a new AccessController coprocessor which, when enabled, performs authorization checks on all cluster operations, using stored access control lists. Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to 0.92 branch and trunk. Thanks again for the reviews. 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 Priority: Critical Fix For: 0.92.0 Attachments: HBASE-3025.1.patch, HBASE-3025_5.patch, HBASE-3025_6.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
[jira] [Updated] (HBASE-3025) Coprocessor based simple access control
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling updated HBASE-3025: - Attachment: HBASE-3025_5.patch Latest patch from review board for testing. 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 Priority: Critical Fix For: 0.92.0 Attachments: HBASE-3025.1.patch, HBASE-3025.2011-02-01.patch, HBASE-3025_5.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
[jira] [Updated] (HBASE-3025) Coprocessor based simple access control
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling updated HBASE-3025: - Attachment: (was: HBASE-3025.2011-02-01.patch) 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 Priority: Critical Fix For: 0.92.0 Attachments: HBASE-3025.1.patch, HBASE-3025_5.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
[jira] [Updated] (HBASE-3025) Coprocessor based simple access control
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-3025: - Priority: Critical (was: Major) Fix Version/s: 0.92.0 This is in way of 0.92 release. 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 Priority: Critical Fix For: 0.92.0 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
[jira] Updated: (HBASE-3025) Coprocessor based simple access control
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-3025: -- Fix Version/s: 0.92.0 Bringing into 0.92. 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 Assignee: Eugene Koontz Fix For: 0.92.0 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HBASE-3025) Coprocessor based simple access control
[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling updated HBASE-3025: - Attachment: HBASE-3025.2011-02-01.patch Updated preview patch for security features. Incorporates proper checking of master operations by implementing MasterObserver. 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 Assignee: Eugene Koontz 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. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HBASE-3025) Coprocessor based simple access control
[ 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
