[
https://issues.apache.org/jira/browse/HBASE-19842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-19842:
-----------------------------------
Description:
Per cell ACLs as currently implemented (HBASE-7662) embed the serialized ACL in
a tag stored with each cell. This was done for performance. This has some
drawbacks, most significantly unnecessary duplication and to grant or revoke
requires a rewrite of every affected cell. We could implement them in a space
efficient (and management efficient) way at the cost of some performance like
so:
First, allow storage of cell level ACLs in the ACL table. Rowkey could be hash
of serialized ACL format. Just have to avoid using rowkeys that associate the
ACL with a cf, or table, or namespace... And handle entries in the ACL tables
which don't conform to today's keying strategy.
Then provide the option for storing the rowkey of an entry in the ACL table in
the cell ACL tag instead of the complete serialization.
The advantages would be reduction of unnecessary duplication, and, like ACLs at
other granularities, a GRANT or REVOKE which updates the ACL table will update
access control rules for all affected cells. The disadvantage would be in order
to process the reference to the ACL for each cell with an ACL reference in a
tag we will need to look up the ACL in the ACL table.
was:
Per cell ACLs as currently implemented (HBASE-7662) embed the serialized ACL in
a tag stored with each cell. This was done for performance. This has some
drawbacks, most significantly unnecessary duplication and to grant or revoke
this requires a rewrite of every affected cell. We could implement them in a
space efficient (and management efficient way) at the cost of some performance
like so:
First, allow storage of cell level ACLs in the ACL table. Rowkey could be hash
of serialized ACL format. Just have to avoid using rowkeys that associate the
ACL with a cf, or table, or namespace... And handle entries in the ACL tables
which don't conform to today's keying strategy.
Then provide the option for storing the rowkey of an entry in the ACL table in
the cell ACL tag instead of the complete serialization.
The advantages would be reduction of unnecessary duplication, and, like ACLs at
other granularities, a GRANT or REVOKE which updates the ACL table will update
access control rules for all affected cells. The disadvantage would be in order
to process the reference to the ACL for each cell with an ACL reference in a
tag we will need to look up the ACL in the ACL table.
> Cell ACLs v2
> ------------
>
> Key: HBASE-19842
> URL: https://issues.apache.org/jira/browse/HBASE-19842
> Project: HBase
> Issue Type: New Feature
> Components: security
> Reporter: Andrew Purtell
> Assignee: Thomas D'Silva
> Priority: Major
>
> Per cell ACLs as currently implemented (HBASE-7662) embed the serialized ACL
> in a tag stored with each cell. This was done for performance. This has some
> drawbacks, most significantly unnecessary duplication and to grant or revoke
> requires a rewrite of every affected cell. We could implement them in a space
> efficient (and management efficient) way at the cost of some performance like
> so:
> First, allow storage of cell level ACLs in the ACL table. Rowkey could be
> hash of serialized ACL format. Just have to avoid using rowkeys that
> associate the ACL with a cf, or table, or namespace... And handle entries in
> the ACL tables which don't conform to today's keying strategy.
> Then provide the option for storing the rowkey of an entry in the ACL table
> in the cell ACL tag instead of the complete serialization.
> The advantages would be reduction of unnecessary duplication, and, like ACLs
> at other granularities, a GRANT or REVOKE which updates the ACL table will
> update access control rules for all affected cells. The disadvantage would be
> in order to process the reference to the ACL for each cell with an ACL
> reference in a tag we will need to look up the ACL in the ACL table.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
