Replicating Sentry to Ranger using Hive replication policies
When you create or edit a Hive replication policy, you can choose to migrate the Sentry policies for Hive objects, Impala data, and URLs that are being replicated. The Replication Manager converts the Sentry policies to Ranger policies for the migrated data in the target cluster. The minimum supported Cloudera Manager version 6.3.1 and above is required to replicate Sentry policies to Ranger.
In a Hive replication policy, if you choose the If Sentry permissions were exported from the CDH cluster, import both Hive object and URL permissions or If Sentry permissions were exported from the CDH cluster, import only Hive object permissions option, the Replication Manager performs the following tasks automatically during the replication job run:
When you choose to migrate the Sentry policies to Ranger, the Replication Manager performs the following tasks automatically:
- Exports each Sentry policy as a single JSON file using the authzmigrator tool. The JSON file contains a list of resources, such as URI, database, table, or column and the policies that apply to it.
- Copies the exported Sentry policies to the target cluster using the DistCp tool.
- Ingests the Sentry policies into Ranger after filtering the policies related to the replication job using the authzmigrator tool through the Ranger rest endpoint. To filter the policies, the Replication Manager uses a filter expression that is passed to the authzmigrator tool by Cloudera Manager.
If you are replicating a subset of the tables in a database, database-level policies get converted to equivalent table-level policies for each table being replicated. (For example, ALL on database -> ALL on table individually for each table replicated).
There will be no reference to the original role names in Ranger. The permissions are granted directly to groups and users with respect to the resource and not the role. This is a different format to the Sentry to Ranger migration during an in-place upgrade to CDP Private Cloud Base, which does import and use the Sentry roles.
Regardless of whether a policy was modified or not, each policy will be re-created on each replication. If you wish to continue scheduling data replication but you also want to modify the target cluster’s Ranger policies (and keep those modifications), you should disable the Sentry to Ranger migration on subsequent runs by editing the replication policy and choose the Do not import Sentry Permissions (Default) option.