Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.92.0
    • Component/s: Coprocessors
    • Labels:
      None
    • Hadoop Flags:
      Reviewed
    • 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.

      Description

      Thanks for the clarification Jeff which reminds me to edit this issue.

      Goals of this issue

      1. Client access to HBase is authenticated
      2. User data is private unless access has been granted
      3. 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:

      1. 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.
      2. 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.
      3. 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.

      1. HBASE-3025_6.patch
        189 kB
        Gary Helmling
      2. HBASE-3025_5.patch
        190 kB
        Gary Helmling
      3. HBASE-3025.1.patch
        90 kB
        Andrew Purtell

        Issue Links

          Activity

          Gavin made changes -
          Link This issue depends upon HBASE-2742 [ HBASE-2742 ]
          Gavin made changes -
          Link This issue depends on HBASE-2742 [ HBASE-2742 ]
          Gavin made changes -
          Link This issue depends upon HBASE-3615 [ HBASE-3615 ]
          Gavin made changes -
          Link This issue depends on HBASE-3615 [ HBASE-3615 ]
          Gavin made changes -
          Link This issue depends upon HBASE-2418 [ HBASE-2418 ]
          Gavin made changes -
          Link This issue depends on HBASE-2418 [ HBASE-2418 ]
          Gavin made changes -
          Link This issue depends upon ZOOKEEPER-938 [ ZOOKEEPER-938 ]
          Gavin made changes -
          Link This issue depends on ZOOKEEPER-938 [ ZOOKEEPER-938 ]
          Gavin made changes -
          Link This issue depends upon HBASE-2001 [ HBASE-2001 ]
          Gavin made changes -
          Link This issue depends on HBASE-2001 [ HBASE-2001 ]
          Gavin made changes -
          Link This issue is depended upon by HBASE-3045 [ HBASE-3045 ]
          Gavin made changes -
          Link This issue blocks HBASE-3045 [ HBASE-3045 ]
          Gary Helmling made changes -
          Status Patch Available [ 10002 ] Resolved [ 5 ]
          Hadoop Flags Reviewed [ 10343 ]
          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.
          Resolution Fixed [ 1 ]
          Gary Helmling made changes -
          Attachment HBASE-3025_6.patch [ 12504305 ]
          Gary Helmling made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Gary Helmling made changes -
          Attachment HBASE-3025.2011-02-01.patch [ 12469991 ]
          Gary Helmling made changes -
          Attachment HBASE-3025_5.patch [ 12504183 ]
          stack made changes -
          Fix Version/s 0.92.0 [ 12314223 ]
          Priority Major [ 3 ] Critical [ 2 ]
          Andrew Purtell made changes -
          Assignee Eugene Koontz [ ekoontz ]
          Andrew Purtell made changes -
          Link This issue depends on HBASE-2742 [ HBASE-2742 ]
          Andrew Purtell made changes -
          Link This issue depends on HBASE-3615 [ HBASE-3615 ]
          Andrew Purtell made changes -
          Link This issue relates to HBASE-3615 [ HBASE-3615 ]
          Andrew Purtell made changes -
          Link This issue relates to HBASE-2418 [ HBASE-2418 ]
          Andrew Purtell made changes -
          Link This issue depends on HBASE-2418 [ HBASE-2418 ]
          Eugene Koontz made changes -
          Link This issue relates to HBASE-2418 [ HBASE-2418 ]
          stack made changes -
          Fix Version/s 0.92.0 [ 12314223 ]
          Andrew Purtell made changes -
          Fix Version/s 0.92.0 [ 12314223 ]
          Andrew Purtell made changes -
          Link This issue relates to HBASE-3615 [ HBASE-3615 ]
          Andrew Purtell made changes -
          Link This issue depends on ZOOKEEPER-938 [ ZOOKEEPER-938 ]
          Gary Helmling made changes -
          Attachment HBASE-3025.2011-02-01.patch [ 12469991 ]
          Todd Lipcon made changes -
          Component/s coprocessors [ 12314191 ]
          Jeff Hammerbacher made changes -
          Link This issue relates to HBASE-3435 [ HBASE-3435 ]
          Andrew Purtell made changes -
          Attachment HBASE-3025.1.patch [ 12456090 ]
          Andrew Purtell made changes -
          Link This issue depends on HBASE-2001 [ HBASE-2001 ]
          Andrew Purtell made changes -
          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.
          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.
          Andrew Purtell made changes -
          Link This issue blocks HBASE-3045 [ HBASE-3045 ]
          Andrew Purtell made changes -
          Summary Coprocessor based RBAC policy engine Coprocessor based simple access control
          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.
          Eugene Koontz made changes -
          Link This issue relates to HBASE-1697 [ HBASE-1697 ]
          Eugene Koontz made changes -
          Link This issue blocks HBASE-1697 [ HBASE-1697 ]
          Eugene Koontz made changes -
          Field Original Value New Value
          Link This issue blocks HBASE-1697 [ HBASE-1697 ]
          Andrew Purtell created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Andrew Purtell
            • Votes:
              0 Vote for this issue
              Watchers:
              21 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development