Skip to content

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.

DENY Policy Support

DENY policies are not supported by all connectors, particularly PolicySync Connectors. For specific details, refer to the respective connector documentation.

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:

Policy Field Requirements

Not all fields are mandatory. Also, details for Resource, Tag-Based, and Row-Level policies are under different menu structures.

Basic Policy Information

Field Description
Policy Name A unique name for identifying the policy.
Description Optional field to describe the policy's purpose.
Resource One or more data entities the policy applies to (e.g., database, table, column, path).
Tags Tags (if any) used to classify the resource and apply tag-based policies.

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.

Field Description
Principals Users, groups, or roles to which the policy applies.
Access Types The operations granted or denied (e.g., SELECT, READ, WRITE, DELETE).
Conditions Optional logic (e.g., ABAC expressions or time validity macros) to refine policy enforcement.
Masking/Filtering Optional rules for masking or row-level filtering, usually for SELECT access.
Delegate Admin Specifies if a user or group has permission to manage the policy.
Enabled Determines if the policy is active.

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

Comments