Understanding Ranger policies with RMS

Ranger RMS for HDFS access evaluation workflow

At a high level, the Ranger RMS for HDFS access evaluation workflow is as follows:

• Ranger policies for the HDFS service are evaluated. If any policy explicitly denies access, access is denied.
• Ranger checks to see if the accessed location maps to a Hive table.
• If it does, Hive policies are evaluated for the mapped Hive table. If there is an HDFS policy allowing access, access is allowed. Otherwise, the default HDFS ACLs determine the access.

  Requested HDFS permission is mapped to Hive permissions as follows:

  HDFS ‘read’ ==> Hive ‘select’

  HDFS ‘write’ ==> Hive ‘update’ or ‘alter’

  HDFS ‘execute’ ==> Any Hive permission

• If there is no Hive policy that explicitly allows access to the mapped table, access is denied, otherwise access is allowed.

Appropriate tag policies are considered both during HDFS access evaluation and if needed, during Hive access evaluation phases. Also, one or more log records are generated to indicate which policy, if any, made the access decision.

The following scenarios illustrate how the access permissions are determined. All scenarios assume that the HDFS location is NOT explicitly denied access by a Ranger HDFS policy.

Location does not correspond to a Hive table.

In this case, access will be granted only if a Ranger HDFS policy allows access or HDFS native ACLs allow access. The audit log will show which policy (or Hadoop-acl) made the decision.

Location corresponds to a Hive table.

A Ranger Hive policy explicitly denied access to the mapped table for any of the accesses derived from the original HDFS request.

• Access will be denied by Hive policy.

There is no matching Ranger Hive policy.

• Access will be denied. Audit log will not specify the policy.

Ranger policy masks some columns in the mapped table.

• Access will be denied. Audit log will show Hive masking policy.

Mapped Hive table has a row-filter policy

• Access will be denied. Audit log will show Hive Row-filter policy.

A Ranger Hive policy allows access to the mapped table for the access derived from the original HDFS access request.

• Access will be granted. If the access was originally granted by HDFS policy, the audit log will show HDFS policy.

Ranger RMS for Ozone access evaluation workflow

At a high level, the Ranger RMS for Ozone access evaluation workflow is as follows:

• For every “key” access request made to ranger-ozone-plugin, there are three separate requests are received for authorization as follows:
  • To check READ access on volume
  • To check READ access on bucket
  • To check access made originally for a key
• First two accesses on volume and buckets are determined by Ozone policies in Ranger Admin. RMS will only evaluate access for the key resource.
• Further for the key access evaluation, Ranger policies for the Ozone service are evaluated. If any policy explicitly denies access, access is denied.
• Ranger checks to see if the accessed location (key) maps to a Hive table.
• If it does, Hive policies are evaluated for the mapped Hive table. If there is an OZONE policy allowing access, access is allowed. Otherwise, the access will be denied.
• Requested OZONE permission is mapped to Hive permissions as follows:

  Ozone ACL	Should translate into Hive ACL For Table	Should translate into Hive ACL For Database
  read	select	_any
  write	update	update
  create	create	create
  list	select	select
  delete	drop	drop
  read_acl	select	select
  write_acl	update	update

• If there is no Hive policy that explicitly allows access to the mapped table, access is denied, otherwise access is allowed.
• Appropriate tag policies are considered both during OZONE access evaluation and if needed, during Hive access evaluation phases.
• One or more log records are generated to indicate which policy, if any, made the access decision.