Sentry Policy Replication
During Hive replication from an on-premise CDH cluster to a cloud cluster, the Replication Manager migrates Sentry authorization policies into Ranger as part of the replication policy.
Sentry policy migration takes place as part of a replication policy job. When you create the replication policy, you choose the resources that you want to migrate and the Sentry policies will be migrated for those resources. In the Additional Settings page of the Create Replication Policy wizard, you must select Include Sentry Permissions with Metadata. To perform the Sentry policy replication, you must be running the Sentry service on CDH 5.12 or higher, or any CDH 6.x version. The Ranger version running on your cloud cluster must be 3.1.
The Sentry Permissions section of the Create Replication Policy wizard contains the following options:
- Include Sentry Permissions with Metadata - Select this to migrate Sentry permissions during the replication job.
- Exclude Sentry Permissions with Metadata - Select this if you do not want to migrate Sentry permissions during the replication job.
- Skip URI Privileges - Select this if you do not want to include URI privileges when you migrate Sentry permissions. During the migration, URI privileges are translated to point to an equivalent location in S3. You might not want to migrate URI privileges because if those resources have a different location in S3, the URI privileges will not be valid.
The image below shows the settings in Replication Manager for including Sentry permissions in the replication policy. Click the option to include Sentry permissions, and you have the option of skipping the migration of URI privileges.
The migration of Sentry policies into Ranger is performed in the following operations:
- Export - The export operation runs in the source cluster. During this operation, the Sentry permissions are fetched and exported to a JSON file.
- Translate and Ingest - These operations take place on the target cluster. In the translate operation, Sentry permissions are translated into a format that can be read by Ranger. The permissions are then imported into Ranger. When the permissions are imported, they are tagged with the source cluster name and the time that the ingest took place. After the import, the file containing the permissions is deleted.
A Ranger policy is created for each resource, such as a database, table, or column. The policy name is derived from the resource name. For example, the following resource:
Database:dinosaurs, table= theropods
Would result in this policy:
The priority for migrated policies is set to normal in Ranger. The normal priority allows you to create another policy for the same resource that overrides the policy that is imported from Sentry.