[
https://issues.apache.org/jira/browse/HBASE-13275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14381194#comment-14381194
]
Andrew Purtell edited comment on HBASE-13275 at 3/26/15 1:39 AM:
-----------------------------------------------------------------
Yes. I'm thinking of a limited pilot where you can see the results of grants on
access control in audit logging (of course, this needs that to be functional,
see the latest patch). This allows dry runs where admins/apps can set up ACLs
and see what happens without mistakes causing outages.
bq. permissions will remain after TURN ON?
Of course you'll want to drop the ACL table before starting over with active
enforcement, issuing necessary grants again.
Regarding cell ACLs, ACL tags can be submitted directly by the client via cells
with tags unless the AC is installed. It's no different if the AC is passive.
Either way when you set up for enforcement you'll want to wipe the data and
start new. Or, if this is a case where an insecure application is being
migrated to a secure environment (with or without a passive trial) then we'd
already need a migration tool that sanitizes pre-existing data.
was (Author: apurtell):
Yes. I'm thinking of a limited pilot where you can see the results of grants on
access control in audit logging (of course, this needs that to be functional,
see the latest patch). This allows dry runs where admins/apps can set up ACLs
and see what happens without mistakes causing outages.
bq. permissions will remain after TURN ON?
Of course you'll want to drop the ACL table before starting over with active
enforcement, issuing necessary grants again.
Regarding cell ACLs, ACL tags can be submitted directly by the client via cells
with tags unless the AC is installed. It's no different if the AC is passive.
Either way when you set up for enforcement you'll want to wipe the data and
start new.
> Setting hbase.security.authorization to false does not disable authorization
> ----------------------------------------------------------------------------
>
> Key: HBASE-13275
> URL: https://issues.apache.org/jira/browse/HBASE-13275
> Project: HBase
> Issue Type: Bug
> Reporter: William Watson
> Assignee: Andrew Purtell
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13
>
> Attachments: HBASE-13275.patch, HBASE-13275.patch
>
>
> According to the docs provided by Cloudera (we're not running Cloudera, BTW),
> this is the list of configs to enable authorization in HBase:
> {code}
> <property>
> <name>hbase.security.authorization</name>
> <value>true</value>
> </property>
> <property>
> <name>hbase.coprocessor.master.classes</name>
> <value>org.apache.hadoop.hbase.security.access.AccessController</value>
> </property>
> <property>
> <name>hbase.coprocessor.region.classes</name>
>
> <value>org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.AccessController</value>
> </property>
> {code}
> We wanted to then disable authorization but simply setting
> hbase.security.authorization to false did not disable the authorization
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
