Sentry to Ranger permissions
There are no one-to-one mapping between Sentry privileges and Ranger service policies, therefore the Sentry privileges are translated to their equivalents within the Ranger service policies.
The following list illustrates how the Sentry privileges appear in Ranger after the migration:
- Sentry permissions that are granted to roles are granted to groups in Ranger.
- Sentry permissions that are granted to a parent object are granted to the child object as well. The migration process preserves the permissions that are applied to child objects. For example, a permission that is applied at the database level also applies to the tables within that database.
- Sentry OWNER privileges are translated to the Ranger OWNDER privilege.
- Sentry OWNER WITH GRANT OPTION privileges are translated to Ranger OWNER with Delegated Admin checked.
- Sentry does not differentiate between tables and views. When view permissions are migrated, they are treated as table names.
- Sentry privileges on URIs uses the object store location as the base location.
- If your cluster contains the Kafka service and the Kafka sentry policy had "action": "ALL" permission, the migrated Ranger policy for "cluster" resource will be missing the "alter" permission. This is only applicable for "cluster" resource. You will need to add the policy manually after the upgrade. This missing permission will not have any functional impact. Adding the "alter" permission post upgrade is needed only for completeness because the 'configure' permission will allow alter operations.
The table below shows how actions in Sentry are applied to the corresponding action in Ranger:
|
Sentry Action |
Ranger Action |
|---|---|
|
SELECT |
SELECT |
|
INSERT |
UPDATE |
|
CREATE |
CREATE |
|
REFRESH |
REFRESH |
|
ALL |
ALL |
|
SELECT with Grant |
INSERT |
|
INSERT with Grant |
INSERT |
|
CREATE with Grant |
CREATE |
|
ALL with Grant |
ALL with Delegated Admin Checked |
