HBase
  1. HBase
  2. HBASE-3435

Per-column-qualifier and per-key-value security for HBASE-3025

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: security
    • Labels:
      None

      Description

      Security labels should be assignable on a per-key-value and per-column-qualifer level.

      While simply assigning labels on a k/v level provides a lot of granularity, there will probably be a frequent desire to store labels on a column qualifier level and have fast atomic transactions on labels.

        Issue Links

          Activity

          Hide
          Andrew Purtell added a comment -

          Currently we store per column-family ACLs in the .META.:acl column family, using keys in the form principal,family. We could extend this for column-qualifier specific assignments to: principal,family,qualifier.
          The next step is then enabling authorization checks per column-qualifier, which only becomes tricky in the case of wildcard gets or scans. However, we already have a good user-exposed facility for matching columns to return via filters. So we would create a new AccessControlFilter and inject it (when security is enabled) into user requests via preGet() and preScannerOpen() requests.
          AccessControlFilter would then consult TableAuthManager for each KeyValue and filter out those for which access was denied.
          In the process, the current logic for rejecting requests on a column-family level would need to change to allow requests from users with specific column qualifier access to continue.

          I've done all of this in the context of work for HBASE-6222.

          Show
          Andrew Purtell added a comment - Currently we store per column-family ACLs in the .META.:acl column family, using keys in the form principal,family. We could extend this for column-qualifier specific assignments to: principal,family,qualifier. The next step is then enabling authorization checks per column-qualifier, which only becomes tricky in the case of wildcard gets or scans. However, we already have a good user-exposed facility for matching columns to return via filters. So we would create a new AccessControlFilter and inject it (when security is enabled) into user requests via preGet() and preScannerOpen() requests. AccessControlFilter would then consult TableAuthManager for each KeyValue and filter out those for which access was denied. In the process, the current logic for rejecting requests on a column-family level would need to change to allow requests from users with specific column qualifier access to continue. I've done all of this in the context of work for HBASE-6222 .
          Hide
          Gary Helmling added a comment -

          Enabling per column-qualifier access controls should be fairly straightforward to add to the current state of HBASE-3025.

          Currently we store per column-family ACLs in the .META.:acl column family, using keys in the form principal,family. We could extend this for column-qualifier specific assignments to: principal,family,qualifier.

          The next step is then enabling authorization checks per column-qualifier, which only becomes tricky in the case of wildcard gets or scans. However, we already have a good user-exposed facility for matching columns to return via filters. So we would create a new AccessControlFilter and inject it (when security is enabled) into user requests via preGet() and preScannerOpen() requests.

          AccessControlFilter would then consult TableAuthManager for each KeyValue and filter out those for which access was denied.

          In the process, the current logic for rejecting requests on a column-family level would need to change to allow requests from users with specific column qualifier access to continue.

          Show
          Gary Helmling added a comment - Enabling per column-qualifier access controls should be fairly straightforward to add to the current state of HBASE-3025 . Currently we store per column-family ACLs in the .META.:acl column family, using keys in the form principal , family . We could extend this for column-qualifier specific assignments to: principal , family , qualifier . The next step is then enabling authorization checks per column-qualifier, which only becomes tricky in the case of wildcard gets or scans. However, we already have a good user-exposed facility for matching columns to return via filters. So we would create a new AccessControlFilter and inject it (when security is enabled) into user requests via preGet() and preScannerOpen() requests. AccessControlFilter would then consult TableAuthManager for each KeyValue and filter out those for which access was denied. In the process, the current logic for rejecting requests on a column-family level would need to change to allow requests from users with specific column qualifier access to continue.

            People

            • Assignee:
              Unassigned
              Reporter:
              Ed Kohlwey
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development