Authorization Provider for Impala
Using the BDR service available in CDH you can migrate the permissions in CDP because Ranger is the authorization provider instead of Sentry. You must be aware how Ranger enforces a policy in CDP which may be different from using Sentry.
SHOW ROLEstatements are not supported as Ranger currently does not support roles.
- When a particular resource is renamed, currently, the policy is not automatically transferred to the newly renamed resource.
SHOW GRANTwith an invalid user/group does not return an error.
The following table lists the different access type requirements to run SQL statements in Impala.
|Impala Access Requirement
|VIEW_METADATA on the underlying tables
ALTER TABLE RENAME
|ALL on the target table / view
ALTER on the source table / view
- VIEW_METADATA privilege denotes the
SELECT, INSERT, or REFRESHprivileges.
- ALL privilege denotes the
SELECT, INSERT, CREATE, ALTER, DROP, and REFRESHprivileges.
For more information on the minimum level of privileges and the scope required to run SQL statements in Impala, see Impala Authorization.
Migrating Sentry Policies
As CDP leverages Ranger as its authorization service, you must migrate permissions from Sentry to Ranger. You can use the BDR service available in CDH to migrate the permissions. This service migrates Sentry authorization policies into Ranger as a part of the replication policy job. When you create the replication policy, choose the resources that you want to migrate and the Sentry policies are migrated for those resources. You can migrate all permissions or permissions on a set of objects to Ranger.
Sentry Permissions section of the
Create Replication Policy wizard contains the following
The Replication Option section of the Create Replication Policy wizard contains the following options:
Stages of Migration
Sentry and Ranger have different permission models. Sentry permissions are granted to roles and users. These are translated to permissions for groups and users since Ranger currently does not support roles. This is followed by grouping by resource because Ranger policies are grouped by resource. All the permissions that are granted to a resource are considered a single Ranger policy.
The migration of Sentry policies into Ranger is performed in the following operations:
Because there is no one-to-one mapping between Sentry privileges and Ranger service policies, the Sentry privileges are translated into their equivalents within Ranger service policies. For more information on how Sentry actions is applied to the corresponding action in Ranger, see Sentry to Ranger Permissions.