Ranger (8)

Create a time limit policy

The administrator policy validity period configuration policy takes effect within the specified time period. You can add expiration dates for resource-based and tag-based strategies.

About this task
Examples of time limit strategy use cases:
• Restrict access to sensitive financial information before the earnings release date.
• Block a user for a certain period of time (for example, a user account under investigation needs to be "shelved" and cannot access resources in the Hadoop service).
• Block certain groups for a certain period of time (for example, temporary employees are not allowed to write resources during the holidays).
Note: The following procedure shows how to create a resource-based strategy with a time limit. For tag-based resource strategies, this process is essentially the same.

process

1. On the Administrator Service Manager page, select a service and click "Add New Policy".
2. Complete the fields on the Create Policy page.
3. Click "Add Validity Period".
4. Set the start time, end time and time zone in the pop-up "Policy Validity Period" window. To add an additional validity period, click the + sign. Click "Save" to save the set validity period information.
   
5. If you want this policy to cover all other policies within the validity period, please select "Override".

6. Click Add.

Security zone for administrators
Ranger security zone allows you to organize service resources into multiple security zones.

Overview Overview of the
Ranger safe area.
What is a safe zone?

Allows you to organize resources and tag-based services and policies into separate security areas. You can assign one or more administrators to each security zone. Then, security zone administrators can create and update policies for their security zones.

For example, let us consider two safe areas: "finance" and "sales":

• The safe area "Finance" includes all content in the "Finance" Hive database.
• The security zone "sales" includes all content in the "sales" Hive database.
• In each security zone, a group of users and groups are designated as administrators.
•Users can only create policies in the security zone where the administrator is located.
• The policies defined in the security zone only apply to resources in that zone.
• A zone can be extended to include resources of multiple services, such as HDFS, Hive, HBase, Kafka, etc., allowing a zone administrator to establish 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 cannot be mapped to multiple security zones. Ranger does not allow the creation of security zones to specify resources that match other zone resources. For example, it is not allowed to update the above "finance" area with the HDFS path /sales/finance/*, because this conflicts with the HDFS path /sales/* specified in the "sales" area.
•A group of users and groups can be designated as the administrator of the security zone. The administrator can create, update, and delete security policies for resources in the security zone.
• You can authorize a group of users and groups to view the audit log of access to resources in the security zone. Other users are not allowed to view the access audit logs of resources in this security zone.

Security zone management
•Security zones can only be created, updated or deleted by users with the "ROLE_SYS_ADMIN" role in "Ranger".
•Users can only view, retrieve and update policies in the security zone where they have administrator rights.
How is the security zone used in the authorization process?
When the administrator authorizes the plug-in to request authorization for resource access, it first determines the partition where the accessed resource is located. If the resource matches a certain security zone, only the policy of that security zone is used to authorize access. If the "resource" does not match any security zone, the default (unnamed) security zone strategy is used to authorize access.

Label-based policies
in security zones In a given service, each security zone can be configured to use label-based policies for specific security zones in the label service. In this way, tag-based authorization policies can be used according to the security zone where the resource is located.

Audit log
The audit log generated by the administrator includes the name of the security zone where the resource is accessed. Only users designated as administrators or auditors of this security zone can view the audit log.

Add a Ranger safe zone

How to add a new Ranger safe zone.

process

1. Click "Safe Zone" in the top menu.
   The system displays the "Safe Zone" interface.

2. In the "Security Zone" interface, click the "+" icon.
   
   Go to the "Create Zone" page.
   
   3. Follow the steps below to complete the "Create Zone" page:
   Table 1: zone detail

Field	description
Zone Name	Security zone name.
Zone Description	An optional description.

Table 2: Zone Administration

Field	description
Admin Users	Admin user in the security zone
Admin Usergroups	The Admin user group in the security zone.
Auditor Users	Auditors use users in secure areas.
Auditor Usergroups	Auditor user group in the security zone.

Table 3: service

Field	description
Select Tag Services	Choose a label-based service for the security zone.
Select Resource Services	Select resource-based services for the security zone.

4. The selected service is listed in the Services table. To add a resource for each selected service, click the applicable service in the resource column.
   

5. Use the Add/Edit Resources pop-up window to specify resources for the service, then click Save.
   
   Resources are listed in the "Resources" column of the "Services" table.

6. Click "Save" at the bottom of the "Create Security Zone" interface to save the newly created security zone.
   

7. The newly created security zone will be displayed in the "Security Zone" interface.
   

8. Click the name of the security zone in the "Security Zone" list and click "Edit" to edit the security zone.

9. After the security zone is created, the services assigned to the security zone can be displayed in the "Security Zone" selection box on the "Service Manager" interface. The Zone Name is listed in the Audit> Access page table and also in the Access Manager> Reports table.
   

Manage administrator users, groups, and permissions

To view the list of users and groups that can access the admin portal or its services, select Settings> users / groups in the top menu.

User/group page list:
• Internal users who can log in to the Ranger portal; created by the Ranger console service manager.

• External users who can access the services controlled by the Ranger portal; create on other systems (such as Active Directory, LDAP or UNIX) and synchronize with these systems.

•Admin user: Only the Admin user has the authority to create users and services, run reports, and perform other management tasks. Administrator users can also create sub-policies based on the original policy (basic policy).

• On the group page, click the people icon in the Users column to view the members of the group

Add a user

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

process

1. Choose "Settings>Users/Groups".

The "User/Group" page appears.

2. Click to add a new user. The
user details page appears as follows.

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

Edit a user

How to edit users in Ranger.

process

1. Choose "Settings>Users/Groups".

The user/group page opens to the Users tab.

2. Select the user profile to edit. To edit your own profile, select your user
name and click Profile.

The user details page is presented.

Note:
You can only edit internal users completely. For external users, only user roles can be edited.

3. Edit the user details and click Save.

Delete a user

How to delete users in Ranger.

Before you start,
only users with the admin role can delete users.

process

1. Choose "Settings>Users/Groups".
   The "User/Group" page appears.
   
2. Select the check box in front of the user to be deleted, and click the delete icon on the right side of the user list menu bar.
   
   3. Click OK in the confirmation pop-up window.

Add a group

How to add a group in Ranger.

process

1. Select Settings>Users/Groups, and click the Group tab.
   The "Group" page appears.
   
2. Click "Add New Group."
   The "Group Creation" page appears.
   
   3. Enter a unique name and optional description for the group, and click Save.

Edit a group

How to edit a group in Ranger.

process

1. Select Settings>Users/Groups, and click the Group tab. The
   user group page appears as follows
   
2. Select the name of the group you want to edit.
   
   3. The group edit page appears.
   
3. Edit the group details and click Save.

Delete a group

How to delete a group in Ranger.
Before you start

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

1. Select Settings>Users/Groups, and click the Group tab.
   The "Group" page appears.
   
2. Select the check box of the group you want to delete, and then click the delete icon
   on the right side of the group list menu bar.
   
   3. Click OK in the confirmation pop-up window.

Add/Edit permissions

How to add or edit users or groups in Ranger.

process

1. Select Settings> Permissions.
   The permissions page appears.
   
2. Click the edit icon to
   get the permission you want to edit.

The "Edit Permissions" page appears.

3. Edit the permission settings and click Save.
You can use the + icon to select multiple users and groups.

Manage Ranger reports

As the number of strategies increases, you can use the Reports page to help manage strategies more effectively. This page lists all resource-based and tag-based strategies.

View admin report

How to view the report of the administrator policy.

To view the report of one or more policies, select "Access Manager>Reports". • Click the icon in the "Allow Conditions" column to view the details of the allowable conditions of each policy. You can use the same method to view the details of other policy conditions (allowing exclusion, denying conditions, etc.).

• To edit a policy on the report page, click the policy ID.

Search admin report

Search for the reference information of the Ranger report for one or more strategies.
You can search based on:
•Policy name—Policy name.
• Policy type-the type of policy (access, block, or row-level filter).
•Policy Label—Policy label.
• Components—Strategic resources or label components.
•Resource—The resource path used when creating the policy.
• Security zone name—the name of the security zone.
• Group, Username—The group or user name assigned to the policy.

Export report

Export the reference information reported by the administrator of one or more policies.
You can export the report list in three file formats:

•CSV file
•Excel file
•JSON

Add new components to Apache Ranger

How to add new components to Apache Ranger.
Apache Ranger has three main components:
• Management tools-provide web interface and REST API to manage security policies.
• Component custom authorization module-provide custom authorization in the (Hadoop) component to execute the strategy defined in the management tool.
•UserGroup synchronizer—Allows user/group information in Apache Ranger to be synchronized with enterprise user/group information stored in LDAP or Active Directory.

In order to support the authorization of new components using Apache Ranger, the component details need to be added to Apache Ranger, as shown below:

• Add component details to the management tool.

• Develop custom authorization modules for new components.

Add component details to the management tool

The Apache Ranger management tool supports policy management through a web interface (UI) and supporting (public) REST API. In order to support the new components in the UI and the server, the management tools must be modified.

UI changes required to support new components:

1. Add a new component template on the Service Manager page (console home page):
   display the new component on the Service Manager page (ie, the home page [#!/policymanager]). Apache Ranger needs to add the table template to the Service Manager page and modify it in the corresponding JS file. Ranger also needs to create a new service type enum to distinguish the components that create/update services/policies.
   For example: add a table template to the PolicyManagerLayout_tmpl.html file so that the new component
   js file can be viewed on the Access Manager page related to the new component For example, the data collected by the knox service is passed 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 the service form [AssetForm. properties].
   According to the new component configuration information. This will cause the new configuration fields to be displayed in the corresponding service creation/update page. Please note that AssetForm.js is a common file for each component creation/update service.
   For example: Add new field (configuration) information in AssetForm.js and AssetForm_tmpl.js.

3. Add a new policy list page: Add a new policy list page for the new component in the view policy list.
   For example: create a new KnoxTableLayout.js file, and add js-related changes based on the old component [HiveTableLayout.js]. Go to the list of view policies. Also create a template page, KnoxTableLayout_tmpl.html.

4. Add a new policy creation/update page: Add a policy creation/update page for the new component.
   Also add a policy form JS file and its template to handle all the operations related to the policy form of the new component. For example: Create a new KnoxPolicyCreate.js file for creating/update Knox policies. Create a KnoxPolicyForm.js file to add knox policy field information. Also create a corresponding KnoxPolicyForm_tmpl.html template.

5. Other file changes (if necessary): Change the existing Router.js, Controller.js, XAUtils.js, FormInputList.js, UserPermissionList.js, XAEnums.js, etc. according to our new components (such as Router).

Server changes required for new components:

Let us assume that Apache Ranger supports three components in its portal, and we want to introduce a new component Knox:

1. Create a new service type
   If Apache Ranger is introducing a new component, namely Knox, then they will add a new service type to Knox. That is, serviceType = "Knox". When creating/updating a service/policy, Apache Ranger will distinguish which component the service/policy is created/updated for based on the type of service.

2. Add new required parameters to existing objects, and fill in any component (such as HDFS, Hive, Hbase) policy creation/update objects. Apache Ranger only uses a common object:'VXPolicy. The service creation/update of any component used by Apache Ranger is the same.
   There is only one public object: VXService. Since Apache Ranger has three components, it will have all the required parameters of these three components in'VXPolicy/VXService'. But for Knox, Apache Ranger requires some different parameters, which were not available in previous components. Therefore, it only adds the necessary parameters to the'VXPolicy/VXService' object. When users send a request to the Knox creation/update policy, they will only
   send the parameters required by Knox to create/update the VXPolicy object.
   After adding new parameters to VXPolixy/VXService, Apache Ranger fills the newly added parameters into the corresponding service to map these objects to entity objects.

3. When Apache Ranger uses JPA-EclipseLink to map the database to java, it is necessary to update the entity objects.
   For example, for Knox policy, Apache Ranger adds two new fields ('topology 'and' service') to the db table 'x_resource', it must also update the entity object of the table (ie' XXResource') because it is changing The structure of the table.
   After updating the entity object, Apache Ranger will fill the newly added parameters in the corresponding service (ie XResourceService) so that it can use the updated entity object to communicate with the client.

4. Changing the business logic of the middleware code
   After adding and filling the new required parameters for the new component, Apache Ranger will have to write the business logic to the file "AssetMgr", and it may also need to make some minor changes here. For example, if it wants to create a default policy when creating a service, then Apache Ranger will create a default policy for a given service based on the serviceType. Everything else works, because it is common to all components.

Database changes required for new components:
For service and policy management, Apache Ranger includes the following tables:
• x_asset (for services)
• x_resource (for services)

As mentioned above, if Apache Ranger introduces new components, there is no need to create a separate table for each component in the database. Apache Ranger provides common tables for all components.
If Apache Ranger has three components and wants to introduce a fourth component, then it will add the required fields in these two tables and map them accordingly with the java objects. For example, for Knox, Apache Ranger will add two fields ('topology', 'service') to' x_resource'. After this, it will be able to perform CRUD operations on policies and services for our new components as well as the previous components.