Access Policy Definition in Apache Ranger¶

Apache Ranger provides a unified policy model to control access to data across a variety of services. Policies in Ranger define who can perform what actions on which resources under what conditions. The policy framework supports multiple levels of access control, allowing enterprises to implement both coarse-grained and fine-grained security controls.

Overview¶

Apache Ranger provides a unified policy model for controlling data access across various services. Policies define who can perform what actions on which resources under what conditions. The policy framework supports multiple levels of access control, allowing enterprises to implement both coarse-grained and fine-grained security controls.

Prerequisites¶

Before working with access policies, you should be familiar with: - Basic concepts of access control - Your organization's security requirements - The data services you need to protect - User and group management in your environment

Policy Evaluation Flow¶

In Apache Ranger, by default permissions are DENY unless explicitly allowed. Even if there is an ALLOW policy, there are checks like Policy Conditions or explicit DENY policies that can override the ALLOW policy.

The following flowchart illustrates how Apache Ranger evaluates access requests:

flowchart TD
    A[Request to access resource] --> B[Obtain tags]
    B --> C[Check tag deny]
    C -- Yes --> D1[[DENY]]
    C -- No --> D[Check resource deny]
    D -- Yes --> D1
    D -- No --> E[Check tag allow]
    E -- Yes --> C1[Check Tag Conditions is True]
    C1 -- Yes --> F1[[ALLOW]]
    C1 -- No --> F[Check resource allow]
    E -- No --> F
    F -- No --> D1
    F -- Yes --> C2[Check Resource Conditions is True]
    C2 -- Yes --> F1

Types of Policies¶

Apache Ranger supports three core types of access policies:

1. Resource-Based Policies¶

These are the most common policies in Ranger and are tied directly to specific resources such as databases, tables, or file paths. They are primarily used for Role-Based Access Control (RBAC).

Examples: * Allow SELECT on table sales_data to the group analysts. * Deny DELETE on S3 path /archive/ to the user temp_user.

Read Resource-Based Policies for more details.

2. Tag-Based Policies¶

Tag-based policies allow access control based on classification tags rather than specific resource names. These policies are defined in a dedicated Tag Service and are evaluated based on the tags associated with the resource.

Examples: * Allow access to all data tagged PII only to users in the compliance_team. * Mask columns tagged Confidential for non-admin users.

Read Tag-Based Access Control for more details.

3. Attribute-Based Access Control (ABAC)¶

ABAC policies use dynamic expressions based on user, group, or resource attributes to enforce access control. These expressions can be included in policy conditions, masking rules, or row-level filters.

Examples: * Allow access only if ${{USER.department}} == 'finance'. * Allow access to rows where region = ${{USER.region}}.

Read Attribute-Based Access Control for more details.

Policy Details¶

Policies in Apache Ranger contain several fields that define the target resource (or tags), who has access, what type of access is granted or denied, and under what conditions. Below are the key components:

Basic Policy Information¶

Access Control Components (Policy Items)¶

These are the set of allow or deny rules that map users/groups/roles to access types. There can be multiple policy items within a single policy.

Each policy can have multiple policy items, and within each item, you can define specific users, groups, roles, access types, and even conditions.

Ranger Plugin Policy Evaluation Logic¶

Overview¶

The Ranger plugin determines which policies to apply during resource evaluation based on the security zone association of the resource.

Policy Selection Rules¶

Rule 1: Resource with Single Security Zone¶

When: A resource is associated with exactly one security zone

Action: Use only the tag and resource policies defined for that specific security zone

Example: If a database table belongs to the "Production" security zone, only policies configured for the "Production" zone will be evaluated.

Rule 2: Resource with No Security Zone or Multiple Security Zones¶

When: A resource either:

• Is not associated with any security zone(default zone), OR
• Is associated with multiple security zones

Action: Use the default zone's tag and resource policies for evaluation

Example: If a file has no zone assignment or belongs to both "Development" and "Testing" zones, the default zone policies will be applied.

Summary¶

• Single zone assignment → Use that zone's policies
• No zone or multiple zones → Use default zone policies

This ensures consistent policy enforcement while allowing zone-specific configurations when appropriate.

Setup Required for Enforcing Tag Policies¶

Association of Services:

• It is mandatory, the resource service must be associated with the tag service.

Configuration in Security Zones:

• For resources configured in a security zone, the tag services associated with the resource service must also be configured in the same security zone for the tag policies to be enforced.

Example: If a security zone named s3_zone is created with the privacera_s3 service and access is managed using tag-based policies under the privacera_tag service, then the privacera_tag service must also be added to the privacera_s3 repository and associated with the s3_zone.

Related Topics¶

• Resource-Based Policies
• Tag-Based Access Control
• Attribute-Based Access Control
• Policy Conditions
• Row-Level Filtering