Many access control policies require additional context outside of the resources and security principals that are used by default to evaluate policy decisions. For example, knowledge regarding the time of day and the geographic source of attempted access may dictate whether that access is allowed or denied.
Ranger policy evaluation occurs in three distinct steps, 1) request creation, 2) policy evaluation, and 3) post-evaluation. In order to extend the Ranger plugin for a particular service, the request context has to be enriched. For example, enriching the authorization request with the time of day or originating geographic location is needed to evaluate those policies effectively.
The first step to enriching the request context is to register a Context Enricher with the service in question. For this example, we will use Hive and our goal will be to enrich the context with its geographic origination. Ranger 0.6 includes the RangerFileBasedGeolocationProvider, which can be used to add this context based on a data file in the IP2Location format, as in the below example. We will store this data file on the Ranger server in /etc/ranger/geo.
IP_FROM,IP_TO,COUNTRY_CODE,COUNTRY_NAME,REGION,CITY
10.0.0.255,10.0.3.0,US,United States,California,Santa Clara
20.0.100.80,20.0.100.89,US,United States,Colorado,Broomfield
20.0.100.110,20.0.100.119,US,United States,Texas,Irving
We will register this Context Enricher for the Hive service using the Ranger API. We can first retrieve the service definition via the following GET request, where the authentication credentials and Ranger host URI are updated as appropriate.
curl -u admin:admin -X GET http://$RANGER_HOST:6080/service/public/v2/api/servicedef/name/hive
We will then post this service definition back to the Ranger API, with the following entries added
"contextEnrichers": [
{
"itemId": 1,
"name": "GeoEnricher",
"enricher": "org.apache.ranger.plugin.contextenricher.RangerFileBasedGeolocationProvider",
"enricherOptions": {
"FilePath": "/etc/ranger/geo/geo.txt",
"IPInDotFormat": "true"
}
}
]
We will also need to register the Policy Conditions with this service definition. The Policy Conditions will be used to evaluate the authorization request, along with the usual conditions such as security principal, type of access, and object. In this case, the condition will be based on the value of the LOCATION_COUNTRY_CODE mapped to the IP range in which the source IP falls.
"policyConditions": [
{
"itemId": 1,
"name": "location-outside",
"label": "Accessed from outside of location?",
"description": "Accessed from outside of location?",
"evaluator": "org.apache.ranger.plugin.conditionevaluator.RangerContextAttributeValueNotInCondition",
"evaluatorOptions": {
"attributeName": "LOCATION_COUNTRY_CODE"
}
}
]
We will post this updated service definition by saving the changes in hiveService2.json and using the Ranger API to commit the change.
curl -v -H 'Content-Type: application/json' -u admin:admin -X PUT --data @hiveService2.json http://$RANGER_HOST:6080/service/public/v2/api/servicedef/name/hive
We can now see these Policy Conditions when adding new Hive policies to Ranger.
This policy condition uses the LOCATION_COUNTRY_CODE field, so the condition value is a country code like 'US'
