Details

    • Type: Task
    • Status: Open
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • old issue number:
      542

      Description

      HBase 0.98 will have support for encryption at the column family level. For more information, see HBASE-7544(https://issues.apache.org/jira/browse/HBASE-7544). We should surface this capability through Phoenix.

        Activity

        Hide
        pctony Tony Stevenson added a comment -

        Comment:apurtell:11/11/13 08:52:33 PM:

        assigned

        Show
        pctony Tony Stevenson added a comment - Comment:apurtell:11/11/13 08:52:33 PM: assigned
        Hide
        pctony Tony Stevenson added a comment -

        Comment:apurtell:11/11/13 08:52:34 PM:

        Sounds interesting @jamestaylor . Let me take it. Any thoughts on how?

        Show
        pctony Tony Stevenson added a comment - Comment:apurtell:11/11/13 08:52:34 PM: Sounds interesting @jamestaylor . Let me take it. Any thoughts on how?
        Hide
        pctony Tony Stevenson added a comment -

        Comment:jamestaylor:11/11/13 08:52:34 PM:

        mentioned

        Show
        pctony Tony Stevenson added a comment - Comment:jamestaylor:11/11/13 08:52:34 PM: mentioned
        Hide
        pctony Tony Stevenson added a comment -

        Comment:jamestaylor:11/12/13 04:44:24 AM:

        @apurtell - I'm waiting for your next blog to answer that

        Would it work if at DDL time, one or more properties were specified to define encryption? Properties can be defined both at the table level and the column family level, see [here](http://forcedotcom.github.io/phoenix/_create) for a few examples.

        Any thoughts on how this might interact with -296? Worse-case, if a tenant wants the ability to do encryption, they'd have to have their own physical table. We might be able to have tenant-specific column families, but I think we'd hit a wall in scaling going that route.

        Show
        pctony Tony Stevenson added a comment - Comment:jamestaylor:11/12/13 04:44:24 AM: @apurtell - I'm waiting for your next blog to answer that Would it work if at DDL time, one or more properties were specified to define encryption? Properties can be defined both at the table level and the column family level, see [here] ( http://forcedotcom.github.io/phoenix/_create ) for a few examples. Any thoughts on how this might interact with -296? Worse-case, if a tenant wants the ability to do encryption, they'd have to have their own physical table. We might be able to have tenant-specific column families, but I think we'd hit a wall in scaling going that route.
        Hide
        pctony Tony Stevenson added a comment -

        Comment:apurtell:11/12/13 04:44:24 AM:

        mentioned

        Show
        pctony Tony Stevenson added a comment - Comment:apurtell:11/12/13 04:44:24 AM: mentioned
        Hide
        pctony Tony Stevenson added a comment -

        Comment:apurtell:11/14/13 01:31:13 AM:

        > Any thoughts on how this might interact with -296?

        You mentioned HBASE-7544. This feature provides transparent server side encryption, which protects data after persistence from accidental exposure due to incorrect HDFS level permissions or improper storage volume handling. There is nothing specific a tenant will need to do to access their data even if all are backed by a single shared table. Surfacing this feature might not need more than properties support for CREATE and ALTER.

        Where things can get interesting is if Phoenix wants to also or instead encrypt values in the driver to protect data during transmission or prevent leakage from one user to another. That would be a distinct capability. I filed HBASE-9578(https://issues.apache.org/jira/browse/HBASE-9578) to consider that for the HBase API, but for Phoenix it could and maybe should be handled in the JDBC driver, or possibly the HBase types library if we want to do clever type specific things in a place outside the scope of the Phoenix code base. For some background on that, see the [first comment](https://issues.apache.org/jira/browse/HBASE-9578?focusedCommentId=13771415&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel_comment-13771415) on HBASE-9578. We could consider how the design described in the CSAIL paper can be applied to Phoenix.

        Show
        pctony Tony Stevenson added a comment - Comment:apurtell:11/14/13 01:31:13 AM: > Any thoughts on how this might interact with -296? You mentioned HBASE-7544 . This feature provides transparent server side encryption, which protects data after persistence from accidental exposure due to incorrect HDFS level permissions or improper storage volume handling. There is nothing specific a tenant will need to do to access their data even if all are backed by a single shared table. Surfacing this feature might not need more than properties support for CREATE and ALTER. Where things can get interesting is if Phoenix wants to also or instead encrypt values in the driver to protect data during transmission or prevent leakage from one user to another. That would be a distinct capability. I filed HBASE-9578 ( https://issues.apache.org/jira/browse/HBASE-9578 ) to consider that for the HBase API, but for Phoenix it could and maybe should be handled in the JDBC driver, or possibly the HBase types library if we want to do clever type specific things in a place outside the scope of the Phoenix code base. For some background on that, see the [first comment] ( https://issues.apache.org/jira/browse/HBASE-9578?focusedCommentId=13771415&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel_comment-13771415 ) on HBASE-9578 . We could consider how the design described in the CSAIL paper can be applied to Phoenix.
        Hide
        pctony Tony Stevenson added a comment -

        Comment:jamestaylor:11/14/13 06:36:17 AM:

        My thought with encryption for multi-tenant tables was that different tenants might have different keys for their set of data. If the model is rather that the one "hoster" holds the one single key for the entire table, then I agree there's probably very little we'd need to do to take advantage of this feature.

        Right now, the Phoenix driver is an embedded driver, so there's no additional transmission beyond the HBase client to HBase sever communication.

        Show
        pctony Tony Stevenson added a comment - Comment:jamestaylor:11/14/13 06:36:17 AM: My thought with encryption for multi-tenant tables was that different tenants might have different keys for their set of data. If the model is rather that the one "hoster" holds the one single key for the entire table, then I agree there's probably very little we'd need to do to take advantage of this feature. Right now, the Phoenix driver is an embedded driver, so there's no additional transmission beyond the HBase client to HBase sever communication.
        Hide
        pctony Tony Stevenson added a comment -

        Comment:apurtell:11/14/13 05:12:18 PM:

        I think table/column property support for toggling HBASE-7544 on CFs would be nice and would fully support that feature.

        > Right now, the Phoenix driver is an embedded driver, so there's no additional transmission beyond the HBase client to HBase sever communication.

        Right, I meant from the HBase client to server, but we can handle that already today by negotiating auth-conf level protection with SASL.

        I think most who ask for client side encryption want the additional assurance against leakage of data from one user to an unauthorized one if access control fails or is set up incorrectly. If this becomes a goal of Phoenix, then I recommend looking at HBASE-9578 and skimming the paper mentioned there to get a sense of the potential issues.

        Show
        pctony Tony Stevenson added a comment - Comment:apurtell:11/14/13 05:12:18 PM: I think table/column property support for toggling HBASE-7544 on CFs would be nice and would fully support that feature. > Right now, the Phoenix driver is an embedded driver, so there's no additional transmission beyond the HBase client to HBase sever communication. Right, I meant from the HBase client to server, but we can handle that already today by negotiating auth-conf level protection with SASL. I think most who ask for client side encryption want the additional assurance against leakage of data from one user to an unauthorized one if access control fails or is set up incorrectly. If this becomes a goal of Phoenix, then I recommend looking at HBASE-9578 and skimming the paper mentioned there to get a sense of the potential issues.

          People

          • Assignee:
            Unassigned
            Reporter:
            jamestaylor James Taylor
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development