[ https://issues.apache.org/jira/browse/HBASE-13513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Kyle Purtell resolved HBASE-13513. ----------------------------------------- Resolution: Not A Problem > 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 Kyle Purtell > Priority: Major > > 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 (v8.3.4#803005)