Introduction

This is to introduce a new abstraction in Apache Ranger that would allow carving/bucketing of resources in a service into multiple zones, for better administration of security policies. This would enable multiple administrators to setup security policies for a service – based on the zones to which they have been granted administration rights.

JIRA : RANGER-2232 (Apache JIRA has the detailed functional introduction doc attached to it)

Accessing Zone Feature in Ranger

This section will cover information about details of which role users will have to use zone feature and what are the limitations for each role user for using zone feature. 

Admin

Admin role users has CRUD rights for Zones, irrespective of whether that user is part of Zone Admin/Auditor or not. Admin role users can also manage policies for any zone. 

Zone Admin 

Zone admin can update only 4 properties in Zone such as : 

  • Admin Users

  • Admin UserGroups 

  • Auditor User

  • Auditor UserGroups

Users, that are assigned as Zone Admin in a zone are allowed to create/update/delete policies in services associated with zone. Zone Admin users are allowed to view only their zone’s Access Audits.

Zone Auditor

Any users can be set as zone auditor in a zone. Purpose of zone auditor role user is to view and analyze policies defined for a zone and to view access audits associated with a security zone.

Zone auditor is only allowed to view his/her Zone’s policies and access audits.


Service Admin       


Service Admin role users will be allowed to modify only those services, in which they are marked as service admin : 

  • Add/remove resource based service in a zone.
  • Modify resource combinations for services in a zone,
  • Add/remove tag based services in which they are service admin.

Delegate Admin

If user is delegated admin in policy in that case user is able to create/update/delete zone policies.

Zone Permissions Table for each role users              

Action

Ranger Admin

Service Admin

Zone Admin

Zone Auditor

Delegated Admin

User

Auditor

Create/Update/Delete Service & service-config (including tag-service association)

Y

N

N

N

N

N

N

Get services (* - partial details)

Y

Y*

Y*

Y*

Y*

Y*

Y*

Create/Update/Delete zone

Y

N

N

N

N

N

N

Get zones (* - partial details)

Y

Y*

Y*

Y

Y*

Y*

Y*

Service->Zone association/disassociation

Y

Y

N

N

N

N

N

Add/remove resources to a zone

Y

Y

N

N

N

N

N

Add/remove admins, auditors to a zone

Y

N

Y

N

N

N

N

Create/Update/Delete unzoned policies

Y

Y

N

N

Y

N

N

Create/Update/Delete zone policies

Y

Y

Y

N

Y

N

N

Get unzoned policies

Y

Y

N

N

Y

N

Y

Get zoned policies

Y

Y

Y

Y

Y

N

Y

Other Zone related Rules

  • Users can have different set of policies in the same service : few might be directly related to a zone and few policies might belong to other zone and few might not even belong to any zone. 

  • Policies can not be moved from a zone to another zone.

  • Zone will act as a Traffic Police : which will direct authorization for a resource based on mentioned Resource combination with associated services.
  • For example : If a zone is created with name Finance :
    • Hive : Cl1_hive : Finance
    • Hadoop : cl1_hadoop : /finance/*
    • Kafka : cl1_kafka : Topic : ALL_FINANCE_THREADS
    • This means : user should create policies for all resources belonging to these parent resource categories.

How to get started with Security Zones

Administrators in Ranger can create Security Zone from newly added page of “Security Zones”

  • As part of zone creation, user needs to provide details of :
    • Zone Name and Zone Description :
      • Zone name needs to be unique.
    • Zone Admin Users / Groups :
      • Zone Admin users will be allowed to create / update / delete policies belonging to services associated with the zone.
    • Zone Auditor Users / Groups :
      • A set of users and groups can be authorized to view policies and audit logs of access to zone’s resources. Other users will not be allowed to view access-audit logs of resources of the zone.
    • Services and associated combination of Resources
      • User can select services in which they want to define policies related to that zone and along with services, user can define the combination of Resources, which will be decision maker to authorize all the requests coming to all resources belonging to that resource hierarchy.
    • For example : sample create zone screenshot:

  • After creating zones and defining zone admins, Administrator allows zone admins to manage policies for the resource hierarchy mentioned with associating services.
  • So, now onwards users will see a new filter on landing page of Ranger, to select services based on Security Zone :

  • Zone Admin then can login to Ranger and create policies specific to their own zone.

How will Authorization work ?

  • When a Ranger authorizer plugin authorizes a resource access request, it first determines  whether the resource belongs to one of the zones or not. If resource matches a zone, only the policies of the zone are used to authorize the access.
  • If resource does not match any zone, then the policies in the default (unnamed) zone will be used to authorize the access.
    • For example : two zones are created named as finance and sales
      • Zone: finance
        • service: prod_hadoop; path=/finance/*, /taxes/*
        • service: prod_hive;   database=finance
        • service: prod_kafka;  topic=FIN_*
        • service: test_hadoop; path=/finance/*, /taxes/*
      • Zone: sales
        • service: prod_hadoop; path=/sales/*
        • service: prod_hive;   database=sales
        • service: prod_kafka;  topic=SALES_*
    • If user Adam tries to access a table belonging to finance database, then RangerHiveAuthorizer will check for all policies defined in service prod_hive for finance zone and allow / deny action based on policies defined in finance zone.
    • If user Adam tries to create a new database named as HRD, then  RangerHiveAuthorizer will check for policies defined in service prod_hive for user Adam, as the resource HRD database does not belong to any zone, usual resource based policies will be checked to allow / deny permission to create database.

Audit Logs

  • Zone admins and zone auditors will be able to see access logs which are associated to their zone.
  • If a resource is authorized via a zone based policy then, in Ranger Access audits tab : against that audit event - zone name will be shown.

  • Users can also Filter Access Audit events by Zone Name - to check for authorizations done by zone based policies.

Import / Export of Zone based policies

With introduction of Security Zones feature in Ranger, Import / Export of Ranger policies has been improvised to provide more flexible ways to Import or export Ranger policies.

  • Only Admin role users can import / export policies.
  • Users can perform import / export from any of  the below given combinations :
    • Zone to Zone :
      • This means, user can export policies of all/selected services belonging to a zone and import policies to another cluster on another zone with same type of services.
      • Note : Here, source and destination zone should have exactly the same types of services. For example : On source cluster : Finance zone has two hive services and one hdfs service, then destination cluster needs to have a zone with same set of services i.e. 2 hive services and 1 hdfs service.
    • Zone to Unzone service :
      • This means, user can export policies of all/selected services belonging to a zone and import policies to same type's services (destination service doesn’t have to be part of a zone)
      • Note : Type of services have to be same on source as well as destination for import to be successful.
    • Unzone to Zone’s services
      • Users can import old policies or unzoned policies to a zone, here also service types has to be same. I.e. hive service’s policies can be imported to only hive service type.
    • Unzone to Unzone services
      • This is the oldest and straight forward import / export combination, where user can select source services and destination services of same type and perform import / export.
  • Override Flag during import  : This flag is to delete all policies of destination service before importing source policies. This is an existing feature and works the same way as earlier.
  • Users can Export/Import Resource based policies as well as Tag based policies.
  • Import / Export works the same way on Resource Based Policies as well as Tag Based Policies.





  • No labels