Uploaded image for project: 'HBase'
  1. HBase
  2. HBASE-11095

Add ip restriction in user permissions

Details

    • New Feature
    • Status: Closed
    • Minor
    • Resolution: Won't Fix
    • None
    • None
    • security
    • None

    Description

      For some sensitive data, users want to restrict the from ips of hbase users like mysql access control.

      One direct solution is to add the candidated ips when granting user permisions.

      grant <user|@group[@ip-regular expression]> [ <table> [ <column family> [ <column qualifier> ] ] ]

      Any comments and suggestions are welcomed.
      apurtell

      Attachments

        1. HBASE-11095.patch
          27 kB
          chenxu

        Issue Links

          Activity

            I've thought about this some. We could build a service authorization engine supporting fine grained decisionmaking using attributes such as client IP address (surely the first of many), but consider:

            First, Hadoop already has a nascient service authorization framework, see https://hadoop.apache.org/docs/r2.2.0/hadoop-project-dist/hadoop-common/ServiceLevelAuth.html At least when our secure RPC was first committed we picked up support for service authorization for all of our RPC protocols from the Hadoop libraries. The current Hadoop code does not support IP filtering but it could.

            Second, even if we build our own fine grained service authorization, will Hadoop someday introduce the same facilities? There is HADOOP-9466. Incubating projects like Apache Sentry are also working toward this kind of capability.

            Third, see HBASE-7123 and HBASE-7254. To the extent that technical debt should be paid down in the AccessController, we should factor that in. permissionGranted and the like are where you'd start with today's code to implement restrictions by IP address.

            apurtell Andrew Kyle Purtell added a comment - I've thought about this some. We could build a service authorization engine supporting fine grained decisionmaking using attributes such as client IP address (surely the first of many), but consider: First, Hadoop already has a nascient service authorization framework, see https://hadoop.apache.org/docs/r2.2.0/hadoop-project-dist/hadoop-common/ServiceLevelAuth.html At least when our secure RPC was first committed we picked up support for service authorization for all of our RPC protocols from the Hadoop libraries. The current Hadoop code does not support IP filtering but it could. Second, even if we build our own fine grained service authorization, will Hadoop someday introduce the same facilities? There is HADOOP-9466 . Incubating projects like Apache Sentry are also working toward this kind of capability. Third, see HBASE-7123 and HBASE-7254 . To the extent that technical debt should be paid down in the AccessController, we should factor that in. permissionGranted and the like are where you'd start with today's code to implement restrictions by IP address.

            After considering the above if we would like to proceed, then I recommend a reboot of the authorization code in the AccessController instead of hacking in IP filtering.

            apurtell Andrew Kyle Purtell added a comment - After considering the above if we would like to proceed, then I recommend a reboot of the authorization code in the AccessController instead of hacking in IP filtering.
            liushaohui Shaohui Liu added a comment -

            apurtell
            Thanks for your suggestions
            Agree. We may left this issue here, and keep attention to the refactor of AccessController and the notifications bus.

            liushaohui Shaohui Liu added a comment - apurtell Thanks for your suggestions Agree. We may left this issue here, and keep attention to the refactor of AccessController and the notifications bus.
            apurtell Andrew Kyle Purtell added a comment - - edited I linked this issue to HBASE-7123 , please see https://issues.apache.org/jira/browse/HBASE-7123?focusedCommentId=13989067&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13989067
            javaman_chen chenxu added a comment -

            I upload a patch that can be used as a transient implementation, the primary change is the key of the PermissionCache, that changed from user to user@IP.
            so the grant statement should execute like this:

            grant 'zhangsan@192.168.10.11','R','test'

            means that the user zhangsan can only read the 'test' table at 192.168.10.11

            javaman_chen chenxu added a comment - I upload a patch that can be used as a transient implementation, the primary change is the key of the PermissionCache , that changed from user to user@IP . so the grant statement should execute like this: grant 'zhangsan@192.168.10.11','R','test' means that the user zhangsan can only read the 'test' table at 192.168.10.11
            apurtell Andrew Kyle Purtell added a comment - - edited

            What if we want to grant or revoke to/from a user without care about IP addresses? That's the current capability and the most common use.

            Are these changes backwards compatible? Do they depend on the map type allowing 'null' keys?

            What about actions that are checked outside of request context? They won't have an RPC context to get an IP address from.

            apurtell Andrew Kyle Purtell added a comment - - edited What if we want to grant or revoke to/from a user without care about IP addresses? That's the current capability and the most common use. Are these changes backwards compatible? Do they depend on the map type allowing 'null' keys? What about actions that are checked outside of request context? They won't have an RPC context to get an IP address from.

            People

              Unassigned Unassigned
              liushaohui Shaohui Liu
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: