Ranger AD Integration

Ranger AD Integration: Architecture Overview

When a Ranger plugin for a component (like HBase or HDFS) is activated, Ranger will be in full control of any access. There is a two-way communication between the Ranger plugin and Ranger (Admin) Policy Server (RPS):

Plugins to RPS: Ranger plugins regularly call the RPS to see if new policies were defined in the Ranger Administration Portal (RAP). Generally allow for 30 sec. for a policy to be updated.
RPS to components: The RPS queries the component for meta objects that live on the component to base policies upon (this provides the autocomplete and dropdown list when defining policies.)

The first communication channel (Plugins to RPS) is essential for the plugin to function whereas the second (RPS to components) is optional. It would still be possible to define and enforce policies if the second does not work, but you will not have autocomplete during policy definition.

Configuration details on both communication channels are configured on both Ambari configuration for the component and on the RAP.

Example for HDFS plugin:

The ‘Ranger repository config user’ is the one that involved the second communication channel (RPS to components) for getting metadata from HDFS (like HDFS folders) across. The settings on the HDFS configuration have to match those set at the Ranger end (Access Manager > Resource Based Policies > HDFS > :

To verify if the paramount first communication channel (Plugins to RPS) works can be done by having a look in the RAP at Audit > Plugins:

To verify the second communication channel (RPS to components) press the ‘Test Connection’ button (Access Manager > Resource Based Policies > HDFS > :

If the settings are right you’ll get:

Ranger AD Integration: Ranger Audit

Ranger plugins furthermore send their audit event (whether access was granted or not and based on which policy) directly to the configured sink for audits, which can be HDFS, Solr or both. This is indicated by the yellow arrows in the architectural graph.

The audit access tab on the RAP (Audit > Access) is only populated if Solr is used as sink.

This screen points out an important Ranger feature. When the plugin is enabled AND no specific policy is in place for access to some object, the plugin will fall back to enforcing the standard component level Access Control Lists (ACL’s). For HDFS that would be the user : rwx / group : rwx / other : rwx ACL’s on folders and files.

Once this defaulting to component ACL’s happens the audit events show a ‘ - ‘ in the ‘Policy ID’ column instead of a policy number. If a Ranger policy was in control of allowing/denying the policy number is shown.

Ranger AD Integration: Overview

Rangers AD Integration has 2 levels:

Ranger UI authentication (which users may log on to Ranger itself?)
Ranger User / group sync (which users / groups to define policies for?)

The configuration of both is done entirely on Ambari.