Ranger manages access control through a user interface that ensures consistent policy administration across Hadoop data access components. Security administrators can define security policies at the database, table, column, and file levels, and can administer permissions for specific LDAP-based groups or individual users. Rules based on dynamic conditions such as time or geolocation can also be added to an existing policy rule. The Ranger authorization model is pluggable and can be easily extended to any data source using a service-based definition. Once a user has been authenticated, their access rights must be determined. Authorization defines user access rights to resources. For example, a user may be allowed to create a policy and view reports, but not allowed to edit users and groups. You can use Ranger to set up and manage access to Hadoop services. Ranger enables you to create services for specific Hadoop resources (HDFS, HBase, Hive, etc.) and add access policies to those services. You can also create tag-based services and add access policies to those services. Using tag-based policies enables you to control access to resources across multiple Hadoop components without creating separate services and policies in each component. You can also use Ranger TagSync to synchronize the Ranger tag store with an external metadata service such as Apache Atlas. For more information on Ranger authorization, see the “HDP Security Features” Authorization overview.

Ranger has two types of policies: resource-based and tag-based.

Resource-based policies Ranger enables you to configure resource-based services (HDFS, HBase, Hive, etc.) and add access policies to those services.

Tag-based policies Ranger enables you to create tag-based services and add access policies to those services.

Ranger enables you to create tag-based services and add access policies to those services.

• An important feature of Ranger tag-based authorization is the separation of resource-classification from access- authorization. For example, resources (HDFS file/directory, Hive database/table/column etc.) containing sensitive data such as social security numbers, credit card numbers, or sensitive health care data can be tagged with PII/ PCI/PHI – either as the resource enters the Hadoop ecosystem or at a later time. Once a resource is tagged, the authorization for the tag would be automatically enforced, thus eliminating the need to create or update policies for the resource.
• Using tag-based policies also enables you to control access to resources across multiple Hadoop components without creating separate services and policies in each component.
• Tag details are stored in a tag store. Ranger TagSync can be used to synchronize the tag store with an external metadata service such as Apache Atlas.

Details of tags associated with resources are stored in a tag store. Apache Ranger plugins retrieve the tag details from the tag store for use during policy evaluation. To minimize the performance impact during policy evaluation (in finding tags for resources), Apache Ranger plugins cache the tags and periodically poll the tag store for any changes. When a change is detected, the plugins update the cache. In addition, the plugins store the tag details in a local cache file – just as the policies are stored in a local cache file. On component restart, the plugins will use the tag data from the local cache file if the tag store is not reachable.

Apache Ranger plugins download the tag details from the store managed by Ranger Admin. Ranger Admin persists the tag details in its policy store and provides a REST interface for the plugins to download the tag details.

Ranger Tags can have attributes. Tag attribute values can be used in Ranger tag-based policies to influence the authorization decision. For example, to deny access to a resource after a specific date:

1. Add the EXPIRES_ON tag to the resource.
2. Add an exipry_date tag attribute and set its value to the expiry date.
3. Create a Ranger policy for the EXPIRES_ON tag.
4. Add a condition in this policy to deny access when the date specified the in expiry_date tag attribute is later than the current date.

Note:

The EXPIRES_ON tag policy is created as the default policy in tag service instances.

Ranger TagSync is used to synchronize the tag store with an external metadata service such as Apache Atlas. TagSync is a daemon process similar to the Ranger UserSync process.

Ranger TagSync receives tag details from Apache Atlas via change notifications. As tags are added to, updated, or deleted from resources in Apache Atlas, Ranger TagSync receives notifications and updates the tag store.

When authorizing an access request, an Apache Ranger plugin evaluates applicable Ranger policies for the resource being accessed. The following diagram shows the details of the policy evaluation flow. More details on the steps in this workflow are provided in the subsequent sections.

Apache Ranger Policy Evaluation Flow with Tags

Apache Ranger supports a service to register context enrichers, which are used to update context data to the access request.

The Ranger Tag service, which is part of the tag-based policies feature, adds a context enricher named RangerTagEnricher. This context enricher is responsible for finding tags for the requested resource and adding the tag details to the request context. This context enricher keeps a cache of the available tags; while processing an access request, it finds the tags applicable for the requested resource and adds the tags to the request context. The context enricher keeps the cache updated by periodically polling Ranger Admin for changes.

Once the list of tags for the requested resource is found, the Apache Ranger policy engine evaluates the tag-based policies applicable to the tags. If a policy for one of these tag results in a deny, access will be denied. If none of the tags are denied, and if a policy allows for one of the tags, access will be allowed. If there is no result for any tag, or if there are no tags for the resource, the policy engine will evaluate the resource-based policies to make the authorization decision.

Apache Ranger allows the use of custom conditions while evaluating authorization policies. The Apache Ranger policy engine makes various request details – such as user, groups, resource, and context – available to the conditions. Tags in the request context, which are added by the enricher, are available to the conditions and can be used to influence the authorization decision.

The default policy in tag service instances, the EXPIRES_ON tag, uses such condition to check to see if the request date is later than the value specified in tag attribute expiry_date. This default policy does not work unless an EXPIRES_ON tag has been created in Atlas.

Related Information
Apache Ranger Wiki> Context Enrichers

The Apache Ranger access policy model consists of two major components: specification of the resources a policy is applied to, such as HDFS files and directories, Hive databases. tables. and columns, HBase tables, column-families, and columns, and so on; and the specification of access conditions for specific users and groups

Apache Ranger supports the following access conditions:

• Allow
• Exclude from Allow
• Deny
• Exclude from Deny

These access conditions enable you to set up fine-grained access control policies.

For example, you can allow access to a "finance" database to all users in the "finance" group, but deny access to all users in the "interns" group. Let's say that one of the members of the "interns" group, "scott", needs to work on an assignment that requires access to the "finance" database. In that case, you can add an Exclude from Deny condition that will allow user "scott" to access the "finance" database. The following image shows how this policy would be set up in Apache Ranger:

The deny condition in policies is disabled by default and must be enabled for use.

1. From Ambari>Ranger>Configs>Advanced>Custom ranger-admin-site, add ranger.servicedef.enableDenyAndExceptionsInPolicies=true.
2. Restart Ranger.

Apache Ranger policies are evaluated in a specific order to ensure predictable results (if there is no access policy that allows access, the authorization request will typically be denied). The following diagram shows the policy evaluation work-flow:

This section contains an overview of the Ranger console.

Overview of how to open and close the Ranger console.

To open the Ranger Console, log in to the Ranger portal at http://<your_ranger_server_address>:6080. To log in, enter your user name and password, then click Sign In.

Ranger Console Home Page

Ranger Login Console

After you log in, your user name is displayed at the top right of the Ranger Console.

Explains the basic Ranger console/GUI.

• The Service Manager for Resource Based Policies page is displayed when you log in to the Ranger Console. You can use this page to create services for Hadoop resources (HDFS, HBase, Hive, etc.) and add access policies to those resources.

Clicking Access Manager in the top menu opens the Service Manager for Resource Based Policies page, and also displays a submenu with links to Resource Based Policies, Tag Based Policies, and Reports (this submenu is also displayed when you pass the mouse over the Access Manager link).

• Access Manager > Resource Based Policies -- Opens the Service Manager for Resource Based Policies page. You can use this page to create services for resources (HDFS, HBase, Hive, etc.) and add access policies to those services.
• Access Manager > Tag Based Policies -- Opens the Service Manager for Tag Based Policies page. You can use this page to create tag-based services and add access policies to those services. Using tag-based policies enables you to control access to resources across multiple components without creating separate services and policies in each component.
• Access Manager > Reports -- Opens the Reports page. You can use this page to generate user access reports for resource and tag-based policies based on search criteria such as policy name, resource, group, and user name.
• Audit -- You can use the Audit page to monitor user activity at the resource level, and also to set up conditional auditing based on users, groups, or time. The Audit page includes the Access, Admin, Login Sessions, Plugins, Plugin Status, and User Sync tabs.

• Security Zone -- Lets you organize resource and tag-based services and policies into separate security zones. You can assign one or more administrators for each security zone. Security zone administrators can then create and update policies for their security zone.

• Settings -- Enables you to manage and assign policy permissions to users and groups. Clicking or passing the mouse over Settings displays a submenu with links to the Users/Groups and Permissions pages.

Ranger enables you to configure resource-based services for Hadoop components (e.g. HBase, Kafka, Storm, etc.) and add access policies to those services.

The Service Manager for Resource Based Policies page is displayed when you log in to the Ranger Console. You can also access this page by selecting Access Manager > Resource Based Policies. You can use this page to create services for Hadoop resources (HDFS, HBase, Hive, etc.) and add access policies to those resources.

• To add a new resource-based service, click the Add icon () in the applicable box on the Service Manager page. Enter the required configuration settings, then click Add.
• To edit a resource-based service, click the Edit icon () at the right of the service. Edit the service settings, then click Save to save your changes.
• To delete a resource-based service, click the Delete icon () at the right of the service. Deleting a service also deletes all of the policies for that service.

How to add an HBase service.

Procedure

1. On the Service Manager page, click the Add icon ( ) next to HBase.

The Create Service page appears.

2. Enter the following information on the Create Service page:

Table 1: Service Details

Table 2: Configuration Properties

3. Click Test Connection.
4. Click Add.

How to add an HDFS service.

Procedure

1. On the Service Manager page, click the Add icon () next to HDFS.

The Create Service page appears.

2. Enter the following information on the Create Service page:

Table 3: Service Details

Table 4: Configuration Properties

3. Click Test Connection.
4. Click Add.

How to add a Hive service.

Procedure

1. On the Service Manager page, click the Add icon () next to Hive.

The Create Service page appears.

2. Enter the following information on the Create Service page:

Table 5: Service Details

Table 6: Configuration Properties

3. Click Test Connection.
4. Click Add.

What to do next

Usually, the Ranger Hive service definition uses the HiveServer2 (HS2) JDBC driver to fetch Hive database/table info for resource lookup and testing the connection. Alternatively, you can configure the service definition to use Hive metastore libraries connecting to the Hive metastore database directly. This is recommended when it is difficult to set up HiveServer2 on your cluster, such as when using HDCloud for AWS.

1. Under Ambari>Hive>Configs>Advanced, edit Hive properties:

2. Add the below properties to custom ranger-hive-plugin-properties:

   ranger.service.config.param.enable.hive.metastore.lookup = true

   ranger.service.config.param.hive.site.file.path = /etc/hive/conf/hive-site.xml

3. Save and restart required components.

4. To test the configuration is successful, create a new Hive service and specify the jdbc.url as "none", then run Test Connection.

How to add a Kafka service.

Procedure

1. On the Service Manager page, click the Add icon () next to Kafka.

The Create Service page appears.

2. Enter the following information on the Create Service page:

Table 7: Service Details

Table 8: Configuration Properties

3. Click Test Connection.
4. Click Add.

How to add a Knox service.

Procedure

1. On the Service Manager page, click the Add icon () next to Knox.

The Create Service page appears.

2. Enter the following information on the Create Service page:

Table 9: Service Details

Table 10: Configuration Properties

3. Click Test Connection.
4. Click Add.

How to add a Solr service.

Procedure

1. On the Service Manager page, click the Add icon () next to Solr.

The Create Service page appears.

2. Enter the following information on the Create Service page:

Table 11: Service Details

Table 12: Configuration Properties

3. Click Test Connection.
4. Click Add.

How to add a Storm service.

Procedure

1. On the Service Manager page, click the Add icon () next to Storm.

The Create Service page appears.

2. Enter the following information on the Create Service page:

Table 13: Service Details

Table 14: Configuration Properties

3. Click Test Connection.
4. Click Add.

How to add a YARN service.

Procedure

1. On the Service Manager page, click the Add icon () next to YARN.

The Create Service page appears.

2. Enter the following information on the Create Service page:

Table 15: Service Details

Table 16: Configuration Properties

3. Click Test Connection.
4. Click Add.

How to add an Atlas service.

Procedure

1. On the Service Manager page, click the Add icon () next to Storm.

The Create Service page appears.

2. Enter the following information on the Create Service page:

Table 17: Service Details

Table 18: Configuration Properties

3. Click Test Connection.
4. Click Add.

How to add a NiFi service.

Procedure

1. On the Service Manager page, click the Add icon () next to NiFi.

The Create Service page appears.

2. Enter the following information on the Create Service page:

Table 19: Service Details

Table 20: Configuration Properties

3. Click Test Connection.
4. Click Add.

How to add a NiFi Registry service.

Procedure

1. On the Service Manager page, click the Add icon() next to NiFi Registry.

The Create Service page appears.

2. Enter the following information on the Create Service page:

Table 21: Service Details

Table 22: Configuration Properties

3. Click Test Connection.
4. Click Add.

To view the policies associated with a service, click the service name on the Resource Based Policies Service Manager page. The policies for that service will be displayed in a list, along with a search box.

• To add a new resource-based policy to the service, click Add New Policy.
• To edit a resource-based policy, click the Edit icon( ) at the right of the entry for that service. Edit the policy settings, then click Save to save your changes.
• To delete a resource-based policy, click the Delete icon( ) at the right of the entry for that service.

Related Information
Importing and Exporting Resource-Based Policies

How to add a new policy to an existing HBase service.

Procedure

1. On the Service Manager page, select an existing HBase service.

   The List of Policies page appears.

2. Click Add New Policy.

   The Create Policy page appears.

3. Complete the Create Policy page as follows:

Table 23: Policy Details

Table 24: Allow Conditions

4. You can use the Plus (+) symbol to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.

5. Click Add.

What to do next

Provide User Access to HBase Database Tables from the Command Line HBase provides the means to manage user access to HBase database tables directly from the command line. The most commonly-used commands are:

• GRANT Syntax:

grant '<user-or-group>','<permissions>','<table>

For example, to create a policy that grants user1 read/write permission on the table usertable, the command would be:

grant 'user1','RW','usertable'

The syntax is the same for granting CREATE and ADMIN rights.

• REVOKE Syntax:

revoke '<user-or-group>','<usertable>'

For example, to revoke the read/write access of user1 to the table usertable, the command would be:

revoke 'user1','usertable'

HDP Ranger Authorization Resource-Based Services and Policies

Note:

Unlike Hive, HBase has no specific revoke commands for each user privilege.

Related Information
Wildcards and Variables in Resource-based Policies

How to add a new policy to an existing HDFS service.

About this task

Through configuration, Apache Ranger enables both Ranger policies and HDFS permissions to be checked for a user request. When the NameNode receives a user request, the Ranger plugin checks for policies set through the Ranger Service Manager. If there are no policies, the Ranger plugin checks for permissions set in HDFS.

We recommend that permissions be created at the Ranger Service Manager, and to have restrictive permissions at the HDFS level.

Procedure

1. On the Service Manager page, select an existing HDFS service. The List of Policies page appears.
2. Click Add New Policy. The Create Policy page appears.

3. Complete the Create Policy page as follows:

Table 25: Policy Details

Table 26: Allow Conditions

4. You can use the Plus (+) symbol to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.
5. Click Add.

Related Information
Wildcards and Variables in Resource-based Policies

How to add a new policy to an existing Hive service.

Procedure

1. On the Service Manager page, select an existing Hive service. The List of Policies page appears.

2. Click Add New Policy.

   The Create Policy page appears.

3. Complete the Create Policy page as follows:

Table 27: Policy Details

Table 28: Allow Conditions

4. You can use the Plus (+) symbol to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.
5. Click Add.

What to do next

Provide User Access to Hive Database Tables from the Command Line Hive provides the means to manage user access to Hive database tables directly from the command line. The most commonly-used commands are:

• GRANT Syntax:

grant <permissions> on table <table> to user <user or group>;

For example, to create a policy that grants user1 SELECT permission on the table default-hivesmoke22074, the command would be:

grant select on table default.hivesmoke22074 to user user1;

The syntax is the same for granting UPDATE, CREATE, DROP, ALTER, INDEX, LOCK, ALL, and ADMIN rights.

• REVOKE

HDP Ranger Authorization Resource-Based Services and Policies

Syntax:

revoke <permissions> on table <table> from user <user or group>;

For example, to revoke the SELECT rights of user1 to the table default.hivesmoke22074, the command would be:

revoke select on table default.hivesmoke22074 from user user1;

The syntax is the same for revoking UPDATE, CREATE, DROP, ALTER, INDEX, LOCK, ALL, and ADMIN rights.

Related Information
Wildcards and Variables in Resource-based Policies

How to add a new policy to an existing Kafka service.

Procedure

1. On the Service Manager page, select an existing Kafka service.

   The List of Policies page appears.

2. Click Add New Policy.

   The Create Policy page appears.

3. Complete the Create Policy page as follows:

Table 29: Policy Details

Table 30: Allow Conditions

4. You can use the Plus (+) symbol to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.

5. Click Add.

Related Information
Wildcards and Variables in Resource-based Policies

How to add a new policy to an existing Knox service.

Procedure

1. On the Service Manager page, select an existing Knox service. The List of Policies page appears.

2. Click Add New Policy. The Create Policy page appears.

3. Complete the Create Policy page as follows:

Table 31: Policy Details

Table 32: Allow Conditions

4. You can use the Plus (+) symbol to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.

5. Click Add.

Related Information
Wildcards and Variables in Resource-based Policies

How to add a new policy to an existing Solr service.

Procedure

1. On the Service Manager page, select an existing Solr service. The List of Policies page appears.

2. Click Add New Policy.

   The Create Policy page appears.

3. Complete the Create Policy page as follows:

Table 33: Policy Details

Table 34: Allow Conditions

4. You can use the Plus (+) symbol to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.

5. Click Add.

Related Information
Wildcards and Variables in Resource-based Policies

How to add a new policy to an existing Storm service.

Procedure

1. On the Service Manager page, select an existing Storm service. The List of Policies page appears.

2. Click Add New Policy. The Create Policy page appears.

3. Complete the Create Policy page as follows:

Table 35: Policy Details

Table 36: Allow Conditions

Table 37: Storm User and Group Permissions

4. You can use the Plus (+) symbol to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.

5. Click Add.

Related Information
Wildcards and Variables in Resource-based Policies

How to add a new policy to an existing YARN service.

Procedure

1. On the Service Manager page, select an existing YARN service. The List of Policies page appears.

2. Click Add New Policy.

   The Create Policy page appears.

3. Complete the Create Policy page as follows:

Table 38: Policy Details

Table 39: Allow Conditions

4. Click Add.

Related Information
Wildcards and Variables in Resource-based Policies

How to add a new policy to an existing Atlas service.

Procedure

1. On the Service Manager page, select an existing Atlas service. The List of Policies page appears.

2. Click Add New Policy. The Create Policy page appears.

3. Complete the Create Policy page as follows:

Table 40: Policy Details

Table 41: Allow Conditions

4. You can use the Plus (+) symbol to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.

5. Click Add.

Related Information
Wildcards and Variables in Resource-based Policies

How to add a new policy to an existing Atlas service.

Procedure

1. On the Service Manager page, select an existing NiFi service. The List of Policies page appears.

2. Click Add New Policy.

The Create Policy page appears.

3. Complete the Create Policy page as follows:

Table 42: Policy Details

Table 43: Allow Conditions

4. You can use the Plus (+) symbol to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.

5. Click Add.

How to add a new policy to an existing Atlas service.

Procedure

1. On the Service Manager page, select an existing NiFi Registry service. The List of Policies page appears.

2. Click Add New Policy. The Create Policy page appears.

3. Complete the Create Policy page as follows:

Table 44: Policy Details

Table 45: Allow Conditions

4. You can use the Plus (+) symbol to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.

5. Click Add.

Related Information
NiFi Ranger based policy descriptions
What policy in Ranger should be used for connections in Nifi?

Reference for wildcards and variables in resource-based policies. Ranger Authorization Resource Policy Wildcard Characters Wildcard characters can be included in the resource path, the database name, the table name, or the column name:

• (*) indicates zero or more occurrences of characters
• (?) indicates a single character

Ranger Authorization Resource Policy {USER} Variable

The variable {USER} can be used to autofill the accessing user, for example:

In Select User, choose {USER}.

In Resource Path, enter data_{USER}. Ranger Authorization Resource Policy {USER} Variable Recommended Practices and Customizability

Ranger requires that string '{USER}' is used to represent accessing user as the user in the policy-item in a Ranger policy. However, Ranger provides flexible way of customizing the string that is used as shorthand to represent the accessing user's name in the policy resource specification. By default, Ranger policy resource specification expects characters '{' and '}' as delimiters for string 'USER', however, ranger supports customizable way of specifying delimiter characters, escaping those delimiters, and the string 'USER' itself by prefixing it with another, user-specified string on a per resource-level basis in the service definition of each component supported by Ranger.

For example, if for a certain HDFS installation, if the path names may contain '{' or '}' as valid characters, but not '%' character, then the service-definition for HDFS can be specified as:

"resources": [
{
"itemId": 1,
"name": "path",
"type": "path",
"level": 10,
"parent": "",
"mandatory": true,
"lookupSupported": true,
"recursiveSupported": true,
"excludesSupported": false,
"matcher":
"org.apache.ranger.plugin.resourcematcher.RangerPathResourceMatcher",
"matcherOptions": {"wildcard": true, "ignoreCase": false},
"replaceTokens":true, "tokenDelimiterStart":"%", "tokenDelimiterEnd":"%",
"tokenDelimiterPrefix":"rangerToken:"}
"validationRegEx":"",
"validationMessage": "",
"uiHint":"",
"label": "Resource Path",
"description": "HDFS file or directory
path"
}
]

Corresponding ranger policy for the use case for HDFS will be written as follow:

resource: path=/home/%rangerToken:USER%
user: {USER}
permissions: all, delegateAdmin=true

The following customizable matcherOptions are available for this feature:

• replaceTokens: true if short-hand for user in resource-spec needs to be replaced at run-time with current-user's name; false if the resource-spec needs to be interpreted as it is. Default value: true.
• tokenDelimiterStart: Identifies start character of short-hand for current-user in resource specification. Default value: {.
• tokenDelimiterEnd: Identifies end character of short-hand for current-user in resource specification. Default value:}.
• tokenDelimiterEscape: Identifies escape character for escaping tokenDelimiterStart or tokenDelimiterEnd values in resource specification. Default value: .
• tokenDelimiterPrefix: Identifies special prefix which together with string 'USER' makes up short-hand for current- user's name in the resource specification. Default value:.

You can export and import policies from the Ranger Admin UI for cluster resiliency (backups), during recovery operations, or when moving policies from test clusters to production clusters. You can export/import a specific subset of policies (such as those that pertain to specific resources or user/groups) or clone the entire repository (or multiple repositories) via Ranger Admin UI.

Interfaces

You can import and export policies from the Service Manager page:

You can also export policies from the Reports page:

Table 46: Export Policy Options

Filtering

When exporting from the Reports page, you can apply filters before saving the file. Export Formats.

You can export policies in the following formats:

• Excel
• JSON
• CSV

Note:

CSV format is not supported for importing policies.

When you export policies from the Service Manager page, the policies are automatically downloaded in JSON format. If you wish to export in Excel or CSV format, export the policies from the Reports page dropdown menu.

Required User Roles

The Ranger admin user can import and export only Resource & Tag based policies. The credentials for this user are set in Ranger Configs > Advanced ranger-env in the fields labeled admin_username (default: admin/admin).

The Ranger KMS keyadmin user can import and export only KMS policies. The default credentials for this user are keyadmin/keyadmin.

Limitations

To successfully import policies, use the following database versions:

• MariaDB: 10.1.16+
• MySQL: 5.6.x+
• Oracle: 11gR2+
• PostgreSQL: 8.4+
• MS SQL: 2008 R2+

Partial import is not supported.

Related Information
[Configuring Resource-Based Policies](Configuring Resource-Based Policies)
Importing and Exporting Tag-Based Policies

How to import the policies for a specific service (HBase, YARN, etc).

Procedure

1. On the Service Manager page, click the Import icon for the service:

The Import Policy page appears.

2. Select the file to import.
   You can only import policies in JSON format.

3. (Optional) Configure the import operation: a) The Override Policy option deletes all policies of the destination repositories. b) Zone Mapping – when no destination is selected, all services are imported. When a destination is selected, only the services associated with that security zone are imported. c) Service Mapping maps the downloaded file repository, i.e. source repository to destination repository. You can use the red x symbols to remove services from the import. Scroll down to view all service mappings.

4. Click Import.
   A confirmation message appears after the file is imported.

How to import policies for all services.

Procedure

1. On the Service Manager page, click Import.

The Import Policy page appears.

2. Select the file to import.
   You can only import policies in JSON format.

3. (Optional) Configure the import operation:
   a) The Override Policy option deletes all policies of the destination repositories.
   b) Zone Mapping – when no destination is selected, all services are imported. When a destination is selected, only the services associated with that security zone are imported. c) Service Mapping maps the downloaded file repository, i.e. source repository to destination repository. You can
   use the red x symbols to remove services from the import. Scroll down to view all service mappings.

4. Click Import.
   A confirmation message appears after the file is imported.

Related Information
Import Resource-Based Policies for a Specific Service

How to export the policies for a specific service (HBase, YARN, etc).

About this task

If you wish to export in Excel or CSV format, export the policies from the Reports page dropdown menu.

Procedure

1. On the Service Manager page, click the Export icon for the service:

The Export Policy page appears.

2. Click the Export button.

The file downloads in your browser as a JSON file.

How to export the policies for all service.

About this task

If you would like to export in Excel or CSV format, export the policies from the Reports page dropdown menu.

Procedure

• From the Service Manager page:
  a) Click Export:

The Export Policy page appears.

b) Remove components or specific services, then click Export.

The file downloads in your browser as a JSON file.

• From the Reports page:
  a) Apply filters before exporting the file.
  b) Open the Export drop-down menu:

 c) Select the file format. <br/>
    The file downloads in your browser.

You can use Apache Ranger row-level filters to set access policies for rows in Hive tables. You can also use Ranger column masking to set policies that mask data in Hive columns, for example to show only the first or last four characters of column data.

Row-level filtering helps simplify Hive queries. By moving the access restriction logic down into the Hive layer, Hive applies the access restrictions every time data access is attempted. This helps simplify authoring of the Hive query, and provides seamless behind-the-scenes enforcement of row-level segmentation without having to add this logic to the predicate of the query.

About this task

Row-level filtering also improves the reliability and robustness of Hadoop. By providing row-level security to Hive tables and reducing the security surface area, Hive data access can be restricted to specific rows based on user characteristics (such as group membership) and the runtime context in which this request is issued.

Typical use cases where row-level filtering can be beneficial include:

• A hospital can create a security policy that allows doctors to view data rows only for their own patients, and that allows insurance claims administrators to view only specific rows for their specific site.
• A bank can create a policy to restrict access to rows of financial data based on the employee's business division, locale, or based on the employee's role (for example: only employees in the finance department are allowed to see customer invoices, payments, and accrual data; only European HR employees can see European employee data).
• A multi-tenant application can create logical separation of each tenant's data so that each tenant can see only their own data rows.

You can use Apache Ranger row-level filters to set access policies for rows in Hive tables. Row-level filter policies are similar to other Ranger access policies. You can set filters for specific users, groups, and conditions.

The following conditions apply when using row-level filters:

• The filter expression must be a valid WHERE clause for the table or view.
  
• Each table or view should have its own row-level filter policy.
  
• Wildcard matching is not supported on database or table names.
  
• Filters are evaluated in the order listed in the policy.
  
• An audit log entry is generated each time a row-level filter is applied to a table or view.
  

Procedure

1. On the Service Manager page, select an existing Hive Service.
2. Select the Row Level Filter tab, then click Add New Policy.

3. On the Create Policy page, add the following information for the row-level filter:

Table 47: Policy Details

Table 48: Row Filter Conditions

4. To move a condition in the Row Filter Conditions list (and therefore change the order in which it is evaluated), click the dotted rows icon at the left of the condition row, then drag the condition to a new position in the list.

5. Click Add to add the new row-level filter policy.

You can use Apache Ranger dynamic resource-based column masking capabilities to protect sensitive data in Hive in near real-time. You can set policies that mask or anonymize sensitive data columns (such as PII, PCI, and PHI) dynamically from Hive query output. For example, you can mask sensitive data within a column to show only the first or last four characters.

About this task

Dynamic column masking policies are similar to other Ranger access policies for Hive. You can set filters for specific users, groups, and conditions. With dynamic column-level masking, sensitive information never leaves Hive, and no changes are required at the consuming application or the Hive layer. There is also no need to produce additional protected duplicate versions of datasets.

The following conditions apply when using Ranger column masking policies to mask data returned in Hive query results:

• A variety of masking types are available, such as show last 4 characters, show first 4 characters, Hash, Nullify, and date masks (show only year).
• You can specify a masking type for specific users, groups, and conditions.
• Wildcard matching is not supported.
• Each column should have its own masking policy.
• Masks are evaluated in the order listed in the policy.
• An audit log entry is generated each time a masking policy is applied to a column.

Procedure

1. On the Service Manager page, select an existing Hive Service.
2. Select the Masking tab, then click Add New Policy.
3. On the Create Policy page, add the following information for the column-masking filter:

Table 49: Policy Details

Table 50: Mask Conditions

4. To move a condition in the Mask Conditions list (and therefore change the order in which it is evaluated), click the dotted rows icon at the left of the condition row, then drag the condition to a new position in the list.

5. Click Add to add the new column masking filter policy.

Where Ranger resource-based masking policy for Hive anonymizes data from a Hive column identified by the database, table, and column, tag-based masking policy anonymizes Hive column data based on tags and tag attribute values associated with Hive column (usually specified as metadata classification in Atlas).

About this task

The following conditions apply when using Ranger column masking policies to mask data returned in Hive query results:

• A variety of masking types are available, such as show last 4 characters, show first 4 characters, Hash, Nullify, and date masks (show only year).
• You can specify a masking type for specific users, groups, and conditions.
• Wildcard matching is not supported.
• If there are multiple tag masking policies applied to the same Hive column, the masking policy with the lexicographically smallest policy-name is chosen for enforcement, E.G., policy "a" is enforced before policy "aa".
• Masks are evaluated in the order listed in the policy.
• An audit log entry is generated each time a masking policy is applied to a column.

Procedure

1. Select Access Manager > Tag Based Policies, then select a tag-based service.
2. Select the Masking tab, then click Add New Policy.

3. On the Create Policy page, add the following information for the column-masking filter:

Table 51: Policy Details

Table 52: Mask Conditions

4. You can use the Plus (+) symbols to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.

5. Click Add to add the new policy.

Ranger enables you to create tag-based services and add access policies to those services.

How to add a tag-based service to Ranger.

About this task

You can use the Service Manager for Tag-Based Policies page to create tag-based services and add tag-based access policies that can be applied to Hadoop resources. Using tag-based policies enables you to control access to resources across multiple Hadoop components without creating separate services and policies in each component. You can also use Ranger TagSync to synchronize the Ranger tag store with an external metadata service such as Apache Atlas.

Procedure

1. Select Access Manager > Tag Based Policies, then click the Add icon ( ) in the TAG box on the Service Manager page.

2. On the Create Service page, type in a service name and an optional description. The service is enabled by default, but you can disable it by selecting Disabled. To add the service, click Add.

3. The new tag service appears on the Service Manager page.

Tag-based policies enable you to control access to resources across multiple Hadoop components without creating separate services and policies in each component. You can also use Ranger TagSync to synchronize the Ranger tag store with an external metadata service such as Apache Atlas.

Procedure

1. Select Access Manager> Tag Based Policies, then select a tag-based service.

2. On the List of Policies page, click Add New Policy.

The Create Policy page appears:

3. Enter information on the Create Policy page as follows:

Table 53: Policy Details

Table 54: Allow, Exclude from Allow, Deny, and Exclude from Deny Conditions

4. You can use the Plus (+) symbols to add additional conditions. Conditions are evaluated in the order listed in the policy. The condition at the top of the list is applied first, then the second, then the third, and so on.

5. Click Add to add the new policy.

Using Basic and Advanced Search

Enter boolean expression allows Ranger to use tag attributes and values when configuring tag-based policy Allow or Deny conditions. It allows admins to provide boolean expression(s) using tag attributes.

The policy condition is introduced in the tag service definition:

{
"itemId":2,
"name":"expression",
"evaluator":
"org.apache.ranger.plugin.conditionevaluator.RangerScriptConditionEvaluator",
"evaluatorOptions" : {"engineName":"JavaScript",
"ui.isMultiline":"true"},
"label":"Enter boolean expression",
"description": "Boolean expression"
}

The following variables can be referenced in the boolean expression:

• ctx: Context handler containing APIs to access metadata information from the request.
• tag: Information about the current tag.
• tagAttr: Map containing all the current tag attributes and corresponding values.

The following APIs available from the request:

• getUser(): Returns a string.
• getUserGroups(): Returns a set of strings containing groups.
• getClientIPAddress(): Returns a string containing client IP address.
• getAction(): Returns a string containing information about the action being requested.

For two scenarios:

• User “sam” needs to be denied a policy based on the IP address of the machine from where the resources are accessed.

  Set the deny condition for user sam with the following boolean expression:

if ( tagAttr.get('ipAddr').equals(ctx.getClientIPAddress()) ) {
ctx.result = true;
}

• Deny one particular user, “bob” from a group, “users”, only when this user is accessing resources from a particular IP defined as an tag attribute in Atlas.

Set the deny condition for group users with the following boolean expression:

if (tagAttr.get('ipAddr').equals(ctx.getClientIPAddress()) &&
ctx.getUser().equals("bob")) {
ctx.result=true;
}

Example of how to add a PII tag-based policy. In this example we create a tag-based policy for objects tagged "PII" in Atlas. Access to objects tagged "PII" is allowed for members of the "audit" group. All other users (the "public" group) are denied access.

Procedure

1. Select Access Manager > Tag Based Policies, then select a tag-based service.

2. On the List of Policies page, click Add New Policy.

The Create Policy page appears:

3. Enter the following information on the Create Policy page:

Table 55: Policy Details

Table 56: Allow Conditions

Table 57: Deny Conditions

Table 58: Exclude from Deny Conditions

In this example we used Allow Conditions to grant access to the "audit" group, and then used Deny Conditions to deny access to the "public" group. Because the "public" group includes all users, we then used Exclude from Deny Conditions to exclude the "audit" group, in effect reinstating the "audit" group's original Allow access condition.

4. Click Add to add the new policy.

An EXPIRES_ON tag-based policy is created automatically when a tag service instance created. This default policy denies access to objects tagged with EXPIRES_ON after the expiry date specified in the Atlas tag attribute. You can use the following steps to review the default EXPIRES_ON policy.

Procedure

1. Select Access Manager > Tag Based Policies, then select a tag-based service.

2. On the List of Policies page, click the Edit icon for the default EXIRES_ON policy.

The Edit Policy page appears:

3. We can see that the default EXPIRES_ON policy denies access to all users, and for all components, after the expiry date specified in the Atlas tag attribute.

You can export and import policies from the Ranger Admin UI for cluster resiliency (backups), during recovery operations, or when moving policies from test clusters to production clusters. You can import or export a specific subset of policies (such as those that pertain to specific resources or user/groups) or clone the entire repository (or multiple repositories) via the Ranger Admin UI.

Interfaces

You can import and export policies from the Tag Based Policies page:

You can also export policies from the Reports page:

Table 59: Export Policy Options

Filtering

When exporting from the Reports page, you can apply filters before saving the file.

Export Formats

You can export policies in the following formats:

• Excel
• JSON
• CSV

Note:

CSV format is not supported for importing policies.

When you export policies from the Service Manager page, the policies are automatically downloaded in JSON format. If you wish to export in Excel or CSV format, export the policies from the Reports page dropdown menu.

Required User Roles

The Ranger admin user can import and export only Resource & Tag based policies. The credentials for this user are set in Ranger Configs > Advanced ranger-env in the fields labeled admin_username (default: admin/admin).

The Ranger KMS keyadmin user can import and export only KMS policies. The default credentials for this user are keyadmin/keyadmin.

Limitations

To successfully import policies, use the following database versions:

• MariaDB: 10.1.16+
• MySQL: 5.6.x+
• Oracle: 11gR2+
• PostgreSQL: 8.4+
• MS SQL: 2008 R2+

Partial policy import is not supported.

How to import tag-based policies.

Procedure

1. On the Tag Based Policies page, click one of the Import icons:

2. Select the file to import. You can only import policies in JSON format.

3. (Optional) Configure the import operation: a) The Override Policy option deletes all policies of the destination repositories. b) Zone Mapping – when no destination is selected, all services are imported. When a destination is selected, only the services associated with that security zone are imported. c) Service Mapping maps the downloaded file repository, i.e. source repository to destination repository. You can use the red x symbols to remove services from the import. Scroll down to view all service mappings.

4. Click Import. A confirmation message appears after the file is imported.

How to export all tag-based policies.

About this task

You can only export policies in JSON format from the Tag-based polices page. If you would like to export in Excel or CSV format, export the policies from the Reports page drop-down menu.

Procedure

• From the Access Manager>Tag Based Policies page: a) Click the Export button or icon:

   The Export Policy page appears.
b) Remove components or specific services, then click Export.

c) The file downloads in your browser as a JSON file.

• From the Reports page: a) Filter Component to tag and click Search. b) (Optional) Apply filters before exporting file. c) Open the Export drop-down menu:

d) Select the file format.
   The file downloads in your browser.

Ranger policy validity periods enable you to configure a policy to be effective for a specified time range. You can add a validity period to both resource-based and tag-based policies.

About this task

Time-bound policy use-case examples:

• To restrict access to sensitive financial information until the earnings release date.
• To block a certain user for a specific time period (e.g., a compromised user account being investigated needs to be put on "hold" from accessing resources in Hadoop services).
• To block a certain group for a specific time (e.g., excluding temporary employees from writing on resources during the holiday season).

Note:

The following procedure shows how to create a time-bound resource-based policy. The procedure is essentially the same for a tag-based resource policy.

Procedure

1. On the Ranger Service Manger page, select a service, then click Add New Policy.
2. Complete the fields on the Create Policy page.
3. Click Add Validity Period.
4. On the Policy Validity Period pop-up, specify a start time, end time, and time zone. To add additional validity periods, click the + symbol. Click Save to save the specified validity periods.

5. If you would like the policy to override all other policies during its validity period, select override.

6. Click Add.

Ranger security zones lets you organize service resources into multiple security zones.

Ranger Security Zones overview.

What is a Security Zone?

Lets you organize resource and tag-based services and policies into separate security zones. You can assign one or more administrators for each security zone. Security zone administrators can then create and update policies for their security zone.

For example, let us consider two security zones: "finance" and "sales":

• Security zone "finance" includes all content in a "finance" Hive database.
• Security zone "sales" includes all content in a "sales" Hive database.
• Sets of users and groups are designated as administrators in each security zone.
• Users are allowed to set up policies only in security zones in which they are administrators.
• Policies defined in a security zone are applicable only for resources of that zone.
• A zone can be extended to include resources from multiple services such as HDFS, Hive, HBase, Kafka, etc., allowing administrators of a zone to set up policies for resources owned by their organization across multiple services.

Zone: finance
service: prod_hdfs; path=/finance/*, /taxes/*
service: prod_hive; database=finance
service: prod_kafka; topic=FIN_*
service: test_hadoop; path=/finance/*, /taxes/*
Zone: sales
service: prod_hdfs; path=/sales/*
service: prod_hive; database=sales
service: prod_kafka; topic=SALES_*

• As shown above, resources can be specified using wildcards (FIN_, SALES_).
• A resource is not mappable to more than one security zone. Ranger does not allow creation of security zones that specify resources that match resources in another zone. For example, an attempt to update the "finance" zone above with the HDFS path /sales/finance/* is not be permitted, as this conflicts with the HDFS path /sales/* specified in the "sales" zone.
• A set of users and groups can be designated as administrators of a security zone. Administrators can create, update, and delete security policies for the resources in the security zone.
• A set of users and groups can be authorized to view audit logs of access to a security zone’s resources. Other users are not allowed to view access-audit logs of the security zone resources.

Security Zone Administration

• Security zones can only be created, updated, or deleted by a user with the ROLE_SYS_ADMIN role in Ranger.
  
• Users can view, retrieve, and update policies only in security zones in which they have administrator privileges.

How are Security Zones Used in Authorization?

When a Ranger authorization plugin authorizes a resource access request, it first determines the zone in which the accessed resource resides. If the resource matches a security zone, only the policies of that security zone are used to authorize the access. If resource does not match any security zone, the policies in the default (unnamed) security zone are used to authorize the access.

Tag-based Policies in Security Zones

In a given service, each security zone can be configured to use tag-based policies from a specific security zone in a tag-service. This enables tag-based authorization policies to be used based on the security zone of the resource.

Audit Logs

Audit logs generated by Ranger include the name of the security zone in which the accessed resource resides. Only users who have been assigned as an Admin or Auditor for the security zone are allowed to view the audit logs.

How to add a new Ranger Security Zone.

Procedure

1. Click Security Zone in the top menu. The Security Zone page appears.
2. On the Security Zone page, click the + icon.

The Create Zone page appears.

3. Complete the Create Zone page as follows:

Table 60: Zone Details

Table 61: Zone Administration

Table 62: Services

4. Selected Services are listed in the Services table. To add resources for each selected service, click the + icon in the Resources column for the applicable service.

5. Use the Add/Edit Resources pop-up to specify resources for the service, then click Save.

The resources are listed in the Resources column of the Services table.

6. Click Save at the bottom of the Create Zone page to save the new security zone.

7. The new security zone is listed on the Security Zone page.

8. To edit a security zone, click the security zone name in the Security Zones list, then click Edit.

9. After security zones have been created, you can use the Security Zone selection box on the Service Manager page to display the services assigned to the selected security zone. A Zone Name column appears in the table on the Audit > Access page, and also in the Access Manager > Reports tables.

To view the list of users and groups who can access the Ranger portal or its services, select Settings > Users/Groups in the top menu.

The Users/Groups page lists:

• Internal users who can log in to the Ranger portal; created by the Ranger console Service Manager.
• External users who can access services controlled by the Ranger portal; created at other systems such as Active Directory, LDAP, or UNIX, and synched with those systems.
• Admin users who are the only users with permission to create users and services, run reports, and perform other administrative tasks. Admin users can also create child policies based on the original policy (base policy).
• On the Groups page, you can click the people icons in the Users column to view the members of the applicable group.

How to add a new user to the user list in Ranger.

Procedure

1. Select Settings > Users/Groups.
   The Users/Groups page appears.

2. Click Add New User.
   The User Detail page appears.
   

3. Add the required user details, then click Save.
   The user is immediately added to the list.

How to edit a user in Ranger.

Procedure

1. Select Settings > Users/Groups. The Users/Groups page opens to the Users tab.

2. Select a user profile to edit. To edit your own profile, select your user name, then click Profile

The User Detail page appears.

Note:

You can only fully edit internal users. For external users, you can only edit the user role.

3. Edit the user details, then click Save.

How to delete a user in Ranger.

Before you begin

Only users with the "admin" role can delete a user.

Procedure

1. Select Settings > Users/Groups. The Users/Groups page appears.

2. Select the check box of the user you want to delete, then click the Delete icon ( ) at the right of the User List menu bar.

3. Click OK on the confirmation pop-up.

How to add a group in Ranger

Procedure

1. Select Settings > Users/Groups, then click the Groups tab. The Groups page appears.

2. Click Add New Group. The Group Create page appears.

3. Enter a unique name for the group and an optional description, then click Save.

How to edit a group in Ranger.

Procedure

1. Select Settings > Users/Groups, then click the Groups tab.

The Groups page appears.

2. Select a group name to edit.

3. The Group Edit page appears.

4. Edit the group details, then click Save.

How to delete a group in Ranger.

Before you begin

Only users with the "admin" role can delete a group.

Procedure

1. Select Settings > Users/Groups, then click the Groups tab. The Groups page appears.

2. Select the check box of the group you want to delete, then click the Delete icon ( ) at the right of the Group List menu bar.

3. Click OK on the confirmation pop-up.

What to do next

Users in a deleted group will be reassigned to no group. You can edit these users and reassign them to other groups.

How to add or edit a user or group in Ranger.

Procedure

1. Select Settings > Permissions.
   The Permissions page appears.

2. Click the Edit icon () for the permission you would like to edit.
   

The Edit Permission page appears.

3. Edit the permission settings, then click Save. You can select multiple users and groups using the + icons.

You can use the Reports page to help manage policies more efficiently as the number of policies increases. This page lists all resource-based and tag-based policies.

How to view reports for Ranger policies. To view reports on one or more policies, select Access Manager > Reports.

• To view Allow Condition details for each policy, click the icon in the Allow Conditions column. You can use the same method to view details for other policy conditions (Allow Exclude, Deny Conditions, etc.).
• To edit a policy from the Reports page, click the Policy ID.

Reference information for searching Ranger reports on one or more policies.

You can search based on:

• Policy Name – The policy name.
• Policy Type – The policy type (Access, Masking, or Row Level Filter).
• Policy Label – The policy label.
• Component – The policy resource or tag component.
• Resource – The resource path used when creating the policy.
• Zone Name – The security zone name.
• Group, Username – The group or user name assigned to the policy.

Reference information for exporting Ranger reports on one or more policies. You can export a list of reports in three file formats:

• CSV file
• Excel file
• JSON

How to add a new component to Apache Ranger.

Apache Ranger has three main components:

• Admin Tool -- Provides web interface & REST API for managing security policies.

• Custom Authorization Module for components -- Provides custom authorization within the (Hadoop) component to enforce the policies defined in Admin Tool.

• UserGroup synchronizer -- Enables the user/group information in Apache Ranger to synchronize with the Enterprise user/group information stored in LDAP or Active Directory.

  In order to support new component authorization using Apache Ranger, the component details need to be added to Apache Ranger as follows:

• Add component details to the Admin Tool.

• Develop a custom authorization module for the new component. Adding Component Details to the Admin Tool The Apache Ranger Admin tool supports policy management via both a web interface (UI) and support for a (public) REST API. In order to support a new component in both the UI and the Server, the Admin Tool must be modified.

  Required UI changes to support the new component:

1. Add a new component template to the Service Manager page (console home page): Show new component on the Service Manager page i.e home page[#!/policymanager]. Apache Ranger needs to add table template to Service Manager page and make changes in corresponding JS files. Ranger also needs to create a new service type enum to distinguish the component for which the service/policy is created/updated. For example: Add a table template to PolicyManagerLayout_tmpl.html file to view the new component on the Access Manager page and make changes in the PolicyManagerLayout.js file related to the new component, such as passing knox service collection data to the PolicyManagerLayout_tmpl template. Also create a new service type enum (for example, ASSET_KNOX) in the XAEnums.js file.

2. Add new configuration information to the Service Form: Add new configuration fields to Service Form [AssetForm.js] as per new component configuration information. This will cause the display of new configuration fields in the corresponding service Create/Update page. Please note that the AssetForm.js is a common file for every component to create/update the service. For example: Add new field(configuration) information to AssetForm.js and AssetForm_tmpl.js.

3. Add a new Policy Listing page: Add a new policy listing page for the new component in the View Policy list. For example: Create a new KnoxTableLayout.js file and add JS-related changes as per the old component[HiveTableLayout.js] to the View Policy listing. Also create a template page, KnoxTableLayout_tmpl.html.

4. Add a new Policy Create/Update page: Add a Policy Create/Update page for the new component. Also add a policy form JS file and its template to handle all policy form-related actions for the new component. For example: Create a new KnoxPolicyCreate.js file for Create/Update Knox Policy. Create a KnoxPolicyForm.js file to add knox policy fields information. Also create a corresponding KnoxPolicyForm_tmpl.html template.

5. Other file changes, as needed: Make changes in existing common files as per our new component like Router.js, Controller.js, XAUtils.js, FormInputList.js, UserPermissionList.js, XAEnums.js, etc.

Required server changes for the new component:

Let's assume that Apache Ranger has three components supported in their portal and we want to introduce one new component, Knox:

1. Create New Service Type

   If Apache Ranger is introducing new component i.e Knox, then they will add one new service type for knox. i.e serviceType = “Knox”. On the basis of service type, while creating/updating service/policy, Apache Ranger will distinguish for which component this service/policy is created/updated.

2. Add new required parameters in existing objects and populate objects

   For Policy Creation/Update of any component (i.e HDFS, Hive, Hbase), Apache Ranger uses only one common object, VXPolicy. The same goes for the Service Creation/Update of any component: Apache Ranger uses only one common object VXService. As Apache Ranger has three components, it will have all the required parameters of all of those three components in VXPolicy/VXService. But for Knox, Apache Ranger requires some different parameters which are not there in previous components. Thus, it will add only required parameters into VXPolicy/VXService object.

When a user sends a request to the Knox create/update policy, they will only send the parameters that are required for Knox to create/update the VXPolicy object.

After adding new parameters into VXPolixy/VXService, Apache Ranger populates the newly-added parameters in corresponding services, so that it can map those objects with Entity Object.

3. Add newly-added fields (into database table) related parameters into entity object and populate them

   As Apache Ranger is using JPA-EclipseLink for database mapping into java, it is necessary to update the Entity object. For example, if for Knox policy Apache Ranger has added two new fields (topology and service) into db table x_resource, it will also have to update the entity object of table (i.e XXResource), since it is altering table structure.

   After updating the entity object Apache Ranger will populate newly-added parameters in corresponding services (i.e XResourceService), so that it can communicate with the client using the updated entity object.

4. Change middleware code business logic

   After adding and populating newly required parameters for new component, Apache Ranger will have to write business logic into file AssetMgr, where it may also need to do some minor changes. For example, if it wants to create a default policy while creating the Service, then on the basis of serviceType, Apache Ranger will create one default policy for the given service. Everything else will work fine, as it is common for all components.

Required database changes for the new component:

For service and policy management, Apache Ranger includes the following tables:

• x_asset (for service)
• x_resource (for service)

As written above, if Apache Ranger is introducing new component then it is not required to create individual table in database for each component. Apache Ranger has common tables for all components.

If Apache Ranger has three components and wants to introduce a fourth one, then it will add required fields into these two tables and will map accordingly with java object. For example, for Knox, Apache Ranger will add two fields (topology, service) into x_resource. After this, it will be able to perform CRUD operation of policy and service for our new component, and also for previous components.

How to customize the Ranger Advanced Settings when configuring authentication.

In the Hadoop ecosystem, each component (i.e., Hive, HBase) has its own authorization implementation and ability to plug in a custom authorization module. To implement the centralized authorization and audit feature for a component, the component should support a customizable (or pluggable) authorization module.

The custom component Authorization Plugin should do the following:

• Provide authorization based on Policies defined in Policy Admin Tool
• Provide audit information based on the authorization decisions

Implementing Custom Component Authorization

To implement the custom component authorization plugin, the Ranger common agent framework provides the following functionalities:

• Ability to read all policies from Service Manager for a given service-id
• Ability to log audit information

When the custom authorization module is initialized, the module should do the following:

1. Initiate a REST API call to the “Policy Admin Tool” to retrieve all policies associated with the specific component.
2. Once the policies are available, it should:
   • be built into a custom data structure for enabling the authorization module.
   • kick off the policy updater thread to refresh policies from “Policy Admin Tool” at a regular interval. When the custom authorization module is called to perform authorization of a component action (such as READ action) on a specific component resource (such as /app folder), the authorization module will:

• Identify authorization decision - For each policy:policyList:
  • If (resource in policy auth-requested-resource)
  • If (action-in-policy action-requested
  • If (current-user or current-user-groups or public-group for the policy), Return access-allowed
• Identify auditing needs - For each policy:policyList
  • If (resource in policy auth-requested-resource), return policy.isAuditEnabled()

In a High Availability (HA) environment, the primary and secondary NameNodes must be configured as described in the HDP System Administration Guide.

To enable Ranger in the HDFS HA environment, the HDFS plugin must be set up in each NameNode, and then pointed to the same HDFS service set up in the Security Manager. Any policies created within that HDFS service are automatically synchronized to the primary and secondary NameNodes through the installed Apache Ranger plugin. That way, if the primary NameNode fails, the secondary NameNode takes over and the Ranger plugin at that NameNode begins to enforce the same policies for access control.

When creating the service, you must include the fs.default.name property, and it must be set to the full host name of the primary NameNode. If the primary NameNode fails during policy creation, you can then temporarily use the fs.default.name of the secondary NameNode in the service details to enable directory lookup for policy creation.

If, while the primary NameNode is down, you wish to create new policies, there is a slight difference in user experience when specifying the resource path. If everything is normal, this is a drop-down menu with selectable paths; however, if your cluster is running from the failover node, there will be no drop-down menu, and you will need to manually enter the path.

Primary NameNode failure does not affect the actual policy enforcement. In this setup for HA, access control is enforced during primary NameNode failure by the Ranger plugs at the secondary NameNodes.

For Test Connection to be successful for HBase and HDFS in a Ranger HA environment, complete the following: In /etc/ranger/admin, create a symbolic link between hbase-site.xml and hdfs-site.xml:

cd /etc/ranger/admin
ln -s /etc/hadoop/conf/hdfs-site.xml hdfs-site.xml
ln -s /etc/hbase/conf/hbase-site.xml hbase-site.xml

To access Usersync settings, select the Advanced tab on the Customize Service page. Usersync pulls in users from UNIX, LDAP, or AD and populates Ranger's local user tables with these users.

About this task

Configure advanced User Sync settings for the following:

• Unix
• (Required) LDAP/AD
• (Optional) LDAP/AD
• Automatically Assign ADMIN KEYADMIN Role for External Users

Procedure

• Unix: If you are using UNIX authentication, the default values for the Advanced ranger-ugsync-site properties are the settings for UNIX authentication:

• (Required) LDAP/AD a) LDAP Advanced ranger-ugsync-site Settings

Table 63: LDAP Advanced ranger-ugsync-site Settings

b) AD Advanced ranger-ugsync-site Settings

Table 64: AD Advanced ranger-ugsync-site Settings

• (Optional) LDAP/AD. If you are using LDAP or Active Directory authentication, you may need to update the following properties, depending upon your specific deployment characteristics.

  a) Advanced ranger-ugsync-site Settings for LDAP and AD

Table 65: Advanced ranger-ugsync-site Settings for LDAP and AD

• Only applies when you want to filter out groups. After you have finished specifying all of the settings on the Customize Services page, click Next at the bottom of the page to continue with the installation.

• Automatically Assign ADMIN KEYADMIN Role for External Users. You can use usersync to mark specific external users, or users in a specific external group, with ADMIN or KEYADMIN role within Ranger. This is useful in cases where internal users are not allowed to login to Ranger. a) From Ambari>Ranger>Configs>Advanced>Custom ranger-ugsync-site, select Add Property. b) Add the following properties: - ranger.usersync.role.assignment.list.delimiter = & The default value is &. - ranger.usersync.users.groups.assignment.list.delimiter = : The default value is :. - ranger.usersync.username.groupname.assignment.list.delimiter = , The default value is ,. - ranger.usersync.group.based.role.assignment.rules = ROLE_SYS_ADMIN:u:userName1,userName2&ROLE_SYS_ADMIN:g:groupName1,groupName2&ROLE_KEY_ADMIN:u:userName&ROLE_KEY_ADMIN:g:groupName&ROLE_USER:u:userName3,userName4&ROLE_USER:g:groupName c) Click Add. d) Restart Ranger.

ranger.usersync.role.assignment.list.delimiter = &
ranger.usersync.users.groups.assignment.list.delimiter = :
ranger.usersync.username.groupname.assignment.list.delimiter = ,
ranger.usersync.group.based.role.assignment.rules :
&ROLE_SYS_ADMIN:u:ldapuser_12,ldapuser2

How to configure LDAP SSL using self-signed certs in the default Ranger User Sync TrustStore.

Procedure

1. The default location is /usr/hdp/current/ranger-usersync/conf/mytruststore.jks for the ranger.usersync.truststore.file property.
2. Alternatively, copy and edit the self-signed ca certs.
3. Set the ranger.usersync.truststore.file property to that new cacert file.

cd /usr/hdp/<version>/ranger-usersync
service ranger-usersync stop
service ranger-usersync start

Where cert.pem has the LDAPS cert.

If you do not wish to provide system Database Administrator (DBA) account details to the Ambari Ranger installer, you can use the dba_script.py Python script to create Ranger DB database users without exposing DBA account information to the Ambari Ranger installer. You can then run the normal Ambari Ranger installation without specify a DBA user name and password.

Procedure

1. Download the Ranger rpm using the yum install command: yum install ranger-admin.
2. You should see one file named dba_script.py in the /usr/hdp/current/ranger-admin directory.
3. Get the script reviewed internally and verify that your DBA is authorized to run the script.
4. Execute the script by running the following command: python dba_script.py.
5. Pass all values required in the argument. These should include db flavor, JDBC jar, db host, db name, db user, and other parameters.
   • If you would prefer not to pass runtime arguments via the command prompt, you can update the /usr/hdp/ current/ranger-admin/install.properties file and then run: python dba_script.py -q When you specify the -q option, the script will read all required information from the install.properties file.
   • You can use the -d option to run the script in "dry" mode. Running the script in dry mode causes the script to generate a database script.

python dba_script.py -d /tmp/generated-script.sql

• Anyone can run the script, but it is recommended that the system DBA run the script in dry mode. In either case, the system DBA should review the generated script, but should only make minor adjustments to the script, for example, change the location of a particular database file. No major changes should be made that substantially alter the script -- otherwise the Ranger install may fail. The system DBA must then run the generated script.

6. Run the Ranger Ambari install procedure, but set Setup Database and Database User to No in the Ranger Admin section of the Customize Services page.

For certain users, if you update the passwords on the Ranger Configs page, you must also update the passwords on the Configs page of each Ambari component that has the Ranger plugin enabled. Individual Ambari component configurations are not automatically updated -- the service restart will fail if you do not update these passwords on each component.

• Ranger Admin user -- The credentials for this user are set in Configs > Advanced ranger-env in the fields labeled admin_username (default value: admin) and admin_password (default value: admin).
• Admin user used by Ambari to create repo/policies -- The user name for this user is set in Configs > Admin Settings in the field labeled Ranger Admin username for Ambari (default value: amb_ranger_admin). The password for this user is set in the field labeled Ranger Admin user's password for Ambari. This password is specified during the Ranger installation.

The following image shows the location of these settings on the Ranger Configs page:

This topic lists password requirements for Ranger and Ranger KMS.

Ranger user password requirements:

• Minimum of 8 characters
• Must include at least one alphabetical and one numerical character
• Must not include the following unsupported special characters: " ' \ ` Ranger and Ranger KMS DB user password requirements:
• Must not include the following unsupported special characters: " ' \ ` Ranger database instance password requirements:
• Refer to the password requirements for the applicable database type (MySQL, PostgreSQL, etc.)