[
https://issues.apache.org/jira/browse/HBASE-13513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514614#comment-14514614
]
Lars Hofhansl commented on HBASE-13513:
---------------------------------------
That'd be cool. Unlike HBASE-13512 this can be achieved by an HBase client does
this, though, right?
> Row granularity data keys
> -------------------------
>
> Key: HBASE-13513
> URL: https://issues.apache.org/jira/browse/HBASE-13513
> Project: HBase
> Issue Type: Sub-task
> Components: encryption, security
> Reporter: Andrew Purtell
>
> Currently we can only set data keys at column family granularity. Consider
> support for setting data keys per row. Then tenant specific data keys in a
> multitenant table becomes possible.
> HBASE-13512 proposes to do this per region, which is much easier to achieve
> than what is proposed here, since we'd only vary the existing policy for
> assigning data keys to whole HFiles. However it seems not that difficult to
> do this per row.
> When encrypting HFiles we apply encryption on a per block basis, so per row
> encryption can be achievable if internal to an HFile we are willing to pack
> cells into blocks by row. With per-row encryption active we would start a new
> block after we're done with cells for a given row. The result would be an
> HFile with blocks of varying size each including a data key reference in the
> block header, and presumably the set of relevant data keys stored in a meta
> block. Looks like the HFile writer code will let us do that readily, but
> performance concerns and knock-on effects in block caching could make things
> interesting. Another complication is indexing. If we can say that keys
> themselves are not sensitive, then we don't have to do anything special about
> block indexes. If we cannot say that keys themselves are not sensitive,
> offhand I don't know how to do block indexes, sure we could encrypt leaves of
> the index corresponding to specific data blocks independently, but what to do
> higher in the tree?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
