Acceldata
 ODP
Search documentation… ⌘K

Last updated: Nov 06, 2026 17:09 UTC

Configure Ranger Authorization for Airflow 3

The Ranger plugin provides centralized access control and auditing for Apache Airflow 3. It enables administrators to manage access to DAGs, connections, variables, pools, and other Airflow resources through Apache Ranger.

When enabled, Ranger manages authorization for the Airflow UI and REST API. Airflow continues to handle user authentication through Flask AppBuilder (FAB) or LDAP.

Supported Versions

Component

Version

ODP

3.3.6.6

Apache Airflow

3.2.2

Apache Ranger

2.5.0

Prerequisites

Before enabling the Ranger plugin for Airflow 3, ensure that the following prerequisites are met:

Requirement

Description

Apache Ranger

Install and configure Ranger in the ODP cluster.

Ranger Usersync

Configure Ranger Usersync to synchronize users and groups.

Kerberos

Enable Kerberos authentication. The plugin uses the Airflow keytab to authenticate with Ranger Admin.

Ambari Infra Solr

Install and configure Ambari Infra Solr to store Ranger audit records.

Airflow users

Ensure that users exist in Airflow and their usernames match the corresponding Ranger users.

Enable Ranger Authorization for Airflow 3

To enable Ranger authorization:

  1. Log in to the Ambari UI.
  2. Navigate to Services > AIRFLOW3 > Configs.
  3. Expand Advanced ranger-airflow-plugin-properties.
  4. Select the Enable Ranger for AIRFLOW3 checkbox.
  5. Review the configuration properties and update them if required.
  6. Click Save.
  7. Restart the AIRFLOW3 service to apply the changes.

Ambari automatically performs the following operations:

  • Installs the Ranger plugin on the required hosts.
  • Registers the Airflow service in Ranger.
  • Generates the Ranger policy configuration.
  • Configures the Airflow API server to use Ranger for authorization.

Ranger Plugin Configuration Properties

The following table describes the default configuration properties:

Property

Default

Description

Policy user for Airflow3

ambari-qa

Specifies the owner of the default Ranger policies.

Ranger repository config user

airflow

Specifies the user Ranger Admin uses to retrieve DAG and connection names for autocomplete.

Authz agent port

9183

Specifies the loopback port used by the authorization agent. Change this value if the port is already in use.

Trusted proxies

Empty

Specifies the CIDR ranges of trusted load balancers or proxies. Configure this property only if required.

Verify Ranger Authorization

After restarting AIRFLOW3, verify that Ranger authorization is enabled.

  1. Log in to Ranger Admin.
  2. Navigate to the AIRFLOW service section.
  3. Verify that the following service is available:

<cluster>_airflow

Replace <cluster> with the cluster name.

  1. Log in to the Airflow UI as a user without any Ranger policies.
  2. Verify that:
    • No DAGs appear in the DAG list.
    • Accessing the Connections page returns a permission error.

By default, Ranger denies access to resources unless an applicable policy grants permission.

Supported Resources and Permissions

The Ranger plugin supports authorization for nine Airflow resource types.

Resource

Description

Wildcards

Case-sensitive

dag

Controls access to DAGs using DAG IDs.

Yes

Yes

connection

Controls access to Airflow connections.

Yes

Yes

variable

Controls access to Airflow variables.

Yes

Yes

pool

Controls access to Airflow pools.

Yes

Yes

asset

Controls access to Airflow assets.

Yes

Yes

asset_alias

Controls access to asset aliases.

Yes

Yes

config

Controls access to configuration sections exposed in the Airflow UI.

Yes

No

view

Controls access to built-in Airflow UI views.

Yes

No

custom_view

Controls access to views provided by Airflow plugins.

Yes

Yes

Note: Resource names are case-sensitive except for config and view. For example, a policy configured for Finance_* does not match a DAG named finance_a.

Supported Permissions

The plugin supports the following common permissions:

  • read
  • create
  • edit
  • delete

For DAG resources, the plugin also supports additional permissions.

Category

Permissions

DAG execution

trigger, read_run, edit_run, delete_run

Tasks

read_task, read_task_instance, clear_task

Logs and code

read_logs, read_code

XCom

read_xcom, edit_xcom

Auditing and dependencies

read_audit_log, read_dependencies, read_warning

Versions

read_version

Human-in-the-loop

read_hitl, respond_hitl

These permissions enable administrators to configure granular access to DAG operations.

Create a Ranger Access Policy

Use Ranger Admin to create policies that control access to Airflow resources.

The following example grants the data_eng group read access to DAGs whose IDs begin with etl_.

  1. Log in to Ranger Admin.
  2. Open the <cluster>_airflow service.
  3. Click Add New Policy.
  4. Enter a name for the policy.
  5. Select DAG as the resource type.
  6. Enter etl_* as the resource value.
  7. Under Allow Conditions:
    1. Add the data_eng group.
    2. Select the read permission.
  8. Save the policy.
  9. Wait up to 30 seconds for the policy changes to take effect.

Note: Airflow polls Ranger for policy updates. You do not need to restart Airflow after creating or modifying a policy.

Example Access Policies

The following table provides examples of Ranger access policies for different Airflow resources.

Use case

Resource

Access granted to

Permissions

Allow the Finance team to view its DAGs.

dag = finance_*

Group

read

Allow the ETL team to view and edit its DAGs.

dag = etl_*

Group

read, edit

Allow access to a specific connection.

connection = prod_db

Group

read

Allow deletion of DAG runs.

dag = purge_*

Group

delete

Allow a specific user to view DAGs.

dag = direct_*

User

read

Allow access to specific variables.

variable = var_*

Group

read

Recommendation: Assign policies to groups instead of individual users. Ranger manages group membership, reducing the need to update policies when users join or leave a group.

Verify Resource-Level Access

After configuring policies, log in to Airflow using different user accounts to verify that the appropriate permissions are applied.

The following table illustrates how Ranger filters DAG visibility based on configured policies.

User

Ranger policy

Visible DAGs

Administrator

Access to all DAGs

etl_a, etl_b, finance_a, finance_b, other_a, other_b

Finance team member

dag = finance_*

finance_a, finance_b

ETL team member

dag = etl_*

etl_a, etl_b

User without a policy

None

No DAGs

Ranger filters unauthorized resources from the Airflow UI.

For example:

  • A user with access to connection = prod_db can view only that connection.
  • A user with DAG permissions but no connection permissions receives a permission error when accessing the Connections page.
  • A user without any applicable Ranger policy cannot access the corresponding resources.

View Ranger Audit Logs

The Ranger plugin records authorization decisions, including allowed and denied access requests.

To view audit logs:

  1. Log in to Ranger Admin.
  2. Navigate to Audit > Access.
  3. Filter the audit records by the <cluster>_airflow service.
  4. Review the authorization details.

Each audit record contains the following information:

Field

Description

User

User who initiated the request.

Resource

Airflow resource being accessed.

Permission

Permission requested by the user.

Result

Indicates whether access was allowed or denied.

Client IP

IP address associated with the request.

For resource list operations, the plugin generates a single audit record for the authorization check rather than an individual record for every resource in the list.

Note: Ranger audit records are stored in Solr. HDFS is not supported as an audit destination for this plugin.

Limitations and Considerations

Consider the following limitations when configuring Ranger authorization for Airflow 3.

User Authentication

The Ranger plugin manages authorization only. Airflow continues to authenticate users through FAB or LDAP.

Ensure that:

  • Users have valid Airflow accounts.
  • Usernames match between Airflow and Ranger.
  • Ranger Usersync is configured to resolve group membership.

Policy Synchronization

Policy changes can take up to 30 seconds to take effect because Airflow periodically polls Ranger for updates.

Authorization Service Availability

The Ranger plugin runs an authorization service alongside the Airflow API server.

If the authorization service becomes unavailable, Airflow denies authorization requests instead of falling back to permissive access.

Ambari manages the authorization service lifecycle and automatically restarts the service if it fails.

Kerberos Realm Support

The plugin is designed for single-realm Kerberos deployments.

For cross-realm environments, ensure that the auth_to_local rules correctly map principals from all trusted realms to prevent incorrect user mappings.

Authorization Scope

Ranger authorization applies to:

  • Airflow UI
  • Airflow REST API

It does not apply to the following internal Airflow components:

  • Scheduler
  • Workers
  • Triggerer
  • DAG processor

These components execute tasks using Airflow's internal execution identity rather than individual end-user identities.

Disable Ranger Authorization

To disable Ranger authorization and restore Airflow's built-in role-based access control:

  1. Log in to the Ambari UI.
  2. Navigate to Services > AIRFLOW3 > Configs.
  3. Expand Advanced ranger-airflow-plugin-properties.
  4. Clear the Enable Ranger for AIRFLOW3 checkbox.
  5. Click Save.
  6. Restart the AIRFLOW3 service.

Airflow resumes using its built-in role-based access control.

The Ranger service and existing policies remain available. You can re-enable the plugin later without recreating the policies.