a) The “Create Table/Database” commands of Hive support the Hive “automatic grants” to the newly created tables/databases;
b) The “Alter Table … Rename to …” command support the change of the table name as a Ranger policy resource;
c) The “Drop Table/Database” commands supports the removal of the Ranger policies on the table/database to be dropped.
a) Hive CLI operations are subject to access controls by Ranger as those from a Hive beeline session to a HiveServer2 server;
b) Hive CLI grant/revoke commands are supported against Ranger as those from a Hive beeline session to a HiveServer2 server.
Ranger-1247 (https://issues.apache.org/jira/browse/RANGER-1247)
2.1.1 New Ranger Configurables
hive.metastore.event.listeners = org.apache.ranger.authorization.hive.authorizer.RangerHiveMetastorePrivilegeHandle enables DDL-triggered Range policy updates.
2.1.2 Existing configurables with new, expanded scope
a) hive.security.authorization.manager = org.apache.ranger.authorization.hive.authorizer.RangerHiveAuthorizerFactory enables the Ranger-based authorization for Hive Server2 and Hive CLI.
b) xasecure.hive.update.xapolicies.on.grant.revoke, which controls Hive Ranger policy update from SQL Grant/Revoke commands, will affect Hive CLI grant/revoke operations to Ranger too.
b) policy.grantrevoke.auth.users, which specifies non-admin users who are allowed to do SQL grant/revoke against Ranger, will also control the grant/revoke operations from Hive CLI.
2.2.1 The automatic privilege grants for newly created tables and databases as configured in hive.security.authorization.createtable.user.grants, hive.security.authorization.createtable.group.grants and hive.security.authorization.createtable.role.grants;
2.2.2 The DDL command’ ALTER TABLE … RENAME TO … will cause the corresponding table name changes for the “exactly” matched, vs. pattern-matched, Ranger policies;
2.2.3 The “Drop Table …” command will cause the “exactly” matched Ranger policy to be dropped.
This new feature will be available for both Hive Server2 and Hive CLI.
Failures of the policy updates will not cause the whole operation to fail: the changes on the Database Object are still successful; it is just that the related Ranger policies will not experience the corresponding changes, and that a warning will be logged to the effect.
a) The privilege checks are the same as now by the current HiveServer2 Ranger Plugin;
b) The Grant/Revoke operations are subject to the same privilege checks, and are dependent on the same configuration parameter, xasecure.hive.update.xapolicies.on.grant.revoke, as by the current HiveServer2 Ranger Plugin.
The two configuration parameters of hive.security.authorization.manager and hive.metastore.event.listeners in hive-site.xml enables the Ranger authorization and Ranger policy updates from DDL respectively, for both Hive CLI and HiveServer2; while the same 2 configuration parameters in hiveserver2-site.xml only will enable the two functionalities only for HiveServer2.
The installation script, enable-hive-plugin.sh, adds the two configuration parameters in hive-site.xml, in addition to the existing behavior of adding only the hive.security.authorization.manager configuration parameter to hiveserver2-site.xml, enabling both functionalities for both Hive CLI and HiveServer2.
To enable just the old Ranger Hive Plugin functionalities in HiveServe2, it is required to remove the two configuration parameters from hive-site.xml after installed by the installation script, enable-hive-plugin.sh.
To enable the 2 functionalities just for HiveServer2, after installation by the installation script of enable-hive-plugin.sh, it is required to remove the two configuration parameters from hive-site.xml from hive-site.xml, followed by adding the hive.metastore.event.listeners configuration parameter to hiveserver2-site.xml.
Running the uninstallation script, disable-hive-plugin.sh, will disable all Ranger hooks from Hive CLI and HiveServer2.
Column name changes will not trigger any adjustments of any Ranger Hive policies. It might be added in a future release.
At table creation the automatic owner grants, as specified by the Hive configuration of hive.security.authorization.createtable.owner.grants, are folded into the automatic user grants. Therefore they are not assigned to the unbound Ranger table “{OWNER}” field, and will not be subject to any owner change of the table after creation. That is, the owner grants are fixed as given to the owner of the table at creation.
Note that this is the same behavior as from the native Hive authorizer.