Cloudera Docs

Configuring Ranger ACL Sync

You can configure Ranger ACL sync to view user accees permissions in a manner similar to the HDFS getfacl command after migratng from CDH to CDP.

Introduction

Ranger ACL Sync feature replaces a similar feature previously supported in Sentry. Ranger ACL-Sync is implemented through RMS module which consists of RMS server and chained-plugin and corresponding storage plugin - HDFS/Ozone. Ranger ACL Sync supports viewing access permissions on storage locations across:
  • Ranger policies for storage locations
  • Ranger policies for Hive entities
  • any native storage ACLs
Ranger ACL Sync is considered essential for those customers migrating from CDH to CDP clusters who also used Sentry ACL-sync feature.
Ranger ACL Sync addresses the following customer requirements to support:
  • an operational need for end-users with no access to Ranger-admin to check the permissions on a HDFS resource
  • a tool-set that can verify if the Sentry access permissions are correctly migrated

Sentry implemented an HDFS command getfacl that provided access permissions on a given resource to the end-user in a structured, easy-to-understand form. Ranger ACL-sync is designed to offer the same user experience to the end-users.

Design

The Ranger policy-engine supports an API that, for a resource, returns a static view of the permissions allowed for all users, groups and roles. The view of the access permissions is specific to the component’s access model. In other words, for Hive resource the permissions as defined in the Hive service definition, and for HDFS resource, the view consists of read/write/execute permissions. This functionality is leveraged further, by extending it to chained plugins.

Ranger ACL-sync internally chains HDFS plugin with Hive plugin to provide composite evaluation of access for an HDFS location that maps to a Hive entity. With this extension, the static determination of accesses for a resource considers any chained plugins (and corresponding policy-engine) in its computation. This also requires conversion between Hive access types and HDFS access types, and combining of accesses by multiple (in this case HDFS and Hive) plugins.

The front-end for accessing this static permission map is the getfacl command supported by HDFS. Using this front-end obviates the need for any additional configuration set-up (other than one that enables/disables this feature). It also gives Sentry users (almost) identical experience when interrogating accesses supported for a resource.

Configuration

There are two new configuration parameters introduced for this feature. Both are specified using the safety valve mechanism on HDFS (ranger-hdfs-security.xml).
  1. Go to Cloudera Manager > HDFS > Configuration.
  2. In Search, type ranger-hdfs-security.xml.
  3. In HDFS Service Advanced Configuration Snippet (Safety Valve) for ranger-hdfs-security.xml, add the following properties/values:
    is.facl.interception.enabled=true
    (Default:false): If true, this feature is activated.
    ranger.plugin.hdfs.policyengine.option.disable.role.resolution=true
    (Default:true) : If false, the roles are resolved to their constituent users and groups for reporting the access permissions.
  4. Click Save Changes (CTRL+S).
  5. Restart services with stale configurations.

Limitations

Ranger evaluates access based on static and dynamic (time-based, accessing IP-based, condition-based) policies. The static view of the access permissions given only a resource, is not a complete and always accurate picture. However, for the customers moving from Sentry to Ranger, this may not be an issue.