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.
Related Topics¶
- Resource-Based Policies
- Tag-Based Access Control
- Attribute-Based Access Control
- Policy Conditions
- Row-Level Filtering
- Prev topic: About OLAC
- Next topic: Resource-Based Policies