Ranger plugins
A Ranger plugin is a software that enables integrating a service, for which a plugin is available, into Ranger. Such plugins allow Ranger Admin to control access for the service resources via policies. This article describes the Ranger plugin components and how they interact with Ranger. See the schema in the Ranger architecture article which depicts their role in the Ranger workflow.
Structure
A Ranger plugin consists of two components:
-
Server-side component — a component that exists on the Ranger side.
-
Application-side component — a component that exists on the service side and invokes the Ranger service to check if the end user has permissions for the requested resource.
You can find a detailed description for each component below.
Server-side component
The server-side component consists of a service configuration that should be defined in a JSON file and an implementation of a class that inherits the RangerBaseService class.
Service definition file
The service configuration file has some meta information, but there are also several crucial blocks:
-
Resources. This block contains information about the service resources (e.g. resource name, type, label, etc.).
-
Access types. This block’s items contain information about which actions are possible to perform on the service resources.
-
Configs. The information here represents the user input fields.
A typical configuration file structure looks like this:
{
"id": "<service_id>",
"name": "<service_name>",
"implClass": "<service_class>",
"label": "<service_label>",
"description":"<service_description>",
"resources": [
{
"itemId": 1,
"name": "<resource_name>",
"type": "<resource_type>"
}
],
"accessTypes": [
{
"itemId": 1,
"name": "<action_name>",
"label": "<action_label>"
}
],
"configs": [
{
"itemId": 1,
"name": "<field_name>",
}
],
"enums": [ ],
"contextEnrichers":[ ],
"policyConditions":[ ]
}|
NOTE
Keep in mind, that the purpose of the example above is just to demonstrate the file structure, and many essential fields are omitted.
|
Class implementation
Consider a child of the RangerBaseService class. It expects two functions to be overridden: validateConfig and lookupResource. The former validates values that are passed to the configs section of the service definition file, while the latter enables the autofill of the resource when you are creating a policy in the Ranger Admin UI.
To let the configuration file know which class implements the necessary functionality, the implClass field is used.
Application-side component
The application-side component consists of only one thing — a Ranger authorizer. It’s a class that communicates with the server-side component and checks if a user has access to the requested resource.
This class’s typical workflow is as follows:
-
A requested resource is created.
-
A Ranger request is created using the
RangerAccessRequestclass. Among other things, it includes the resource being requested, the user making the request, and the action that needs to be performed. -
The request is sent using the
isAccessAllowedmethod of theRangerBasePluginclass. -
The response is checked to determine whether the user has access to perform the action of the said resource.
The RangerBasePlugin class requires two files to be present in the class path: ranger-<service-name>-security.xml and ranger-<service-name>-audit.xml.