Apache Ranger Documentation

Apache Ranger operates as a distributed Policy Decision Point (PDP) and Policy Enforcement Point (PEP) system. It is important to understand the following architectural security assumptions:

• Plugin Trust: Ranger treats every plugin (PEP) as fully trusted once authenticated. It does not make cross-node integrity claims to keep runtime overhead low. If a host running a plugin is compromised, the attacker can bypass enforcement locally.
• Authentication vs. Authorization: Ranger provides authorization, not authentication. It assumes the principal (user/service) has already been authenticated by an upstream layer (e.g., Kerberos or LDAP). Ranger cannot defend against a spoofed principal if the upstream authentication is compromised.
• Policy Distribution & Revocation: Policies are distributed from the Admin to plugins via a periodic pull. Because plugins use a local cache when the Admin is unreachable, revocation is not instantaneous. A revoked permission may persist until the next successful policy pull. Operators must size the pull interval based on data sensitivity.
• The 'Deny' is not a Sandbox: Ranger only protects code paths that explicitly consult the Ranger plugin. If a guarded service has a code path that bypasses the plugin, that path is not protected.
• Admin as Root of Trust: The top-level administrator is the root of authority. The model does not protect against a malicious omnipotent administrator.

The Ozone action-matcher feature flag is controlled at runtime via the ranger.servicedef.ozone.enableActionMatcherInPoliciesCondition property in ranger-admin-site.xml.

In the Docker environment, this is mapped from FF_ENABLE_OZONE_ACTION_MATCHES_CONDITION in scripts/admin/ranger-admin-install-<db>.properties.

First-time setup

Set FF_ENABLE_OZONE_ACTION_MATCHES_CONDITION=true in your install properties file, then bring up the services.

Changing the flag later

Option 1: Recreate Admin (Recommended for fresh setup) Edit the property in scripts/admin/ranger-admin-install-<db>.properties and run:

docker compose -f docker-compose.ranger.yml -f docker-compose.ranger-ozone.yml up -d --build --force-recreate ranger

Option 2: Edit live configuration Edit the value directly in the container's ranger-admin-site.xml and restart the Admin container. Note that install.properties is only re-read during the initial setup process, not on a simple restart.

# Verify Ozone configuration via API
curl -s -u admin:rangerR0cks! http://localhost:6080/service/plugins/definitions/name/ozone \
  | python3 -c "import json,sys; d=json.load(sys.stdin); print('options', d.get('options')); print('conditions', [c['name'] for c in d.get('policyConditions',[])])"

The Apache Ranger Authorization API allows applications to programmatically request access decisions for users attempting to perform actions on resources.

Key concepts include:

• User: The actor performing the action, identified by a unique name. Users can have groups, roles, and custom attributes (e.g., department) used in policy evaluation.
• Resource: The object being accessed, identified by a name in the format resource-type:resource-value (e.g., path:/etc/config, table:db.table, object:s3a://bucket/file). Resources can have attributes and sub-resources (e.g., columns within a table).
• Action: The operation being performed (e.g., QUERY, LIST, CREATE). Note that the action in the request is primarily for auditing and does not drive the decision; the decision is driven by the requested Permissions.
• Permission: The specific privilege required for an action (e.g., select, insert, read, write).
• Context: Metadata about the request used for policy decisions, such as serviceName, accessTime, clientIpAddress, and additionalInfo (e.g., clusterName).
• Decision: The outcome of the request, which is either ALLOWED or DENIED.
• Row Filter: A mechanism for row-level security. If a policy defines a row filter, the response includes a filterExpr that the caller must apply to the data to ensure the user only sees authorized rows.
• Data Mask: A mechanism for column-level security. The response can include a dataMask (containing maskType and maskedValue) that the caller must apply to sensitive data to transform it (e.g., masking a credit card number).

Because Ranger is a distributed system, different actors have different trust levels and responsibilities:

Important Note on Authentication: Ranger does not authenticate the end user at access time. The host data service (e.g., HDFS, Hive) is responsible for establishing the principal's identity (e.g., via Kerberos). Ranger then authorizes the identity presented by the host service.

The Ranger Audit Server is a microservices-based system designed to ingest, transport, and dispatch audit events. The data flow follows this pattern:

1. Ranger Plugins send audit events via REST API to the Audit Server.
2. The Audit Server (ranger-audit-ingestor) acts as a producer, receiving events and producing them to a Kafka topic.
3. Dispatcher Services act as consumers, reading from Kafka and writing to various destinations:
   • Solr Dispatcher: Indexes audits into Solr.
   • HDFS Dispatcher: Writes audits to HDFS, S3, or Azure.
   • Other Dispatchers: The architecture allows for Nth dispatchers to be added for new destinations.

┌─────────────────────┐
│  Ranger Plugins     │
│  (HDFS, Hive, etc.) │
└──────────┬──────────┘
           │ REST API
           ▼
┌─────────────────────┐
│ Audit Server        │  Port 7081
│ (Producer)          │
└──────────┬──────────┘
           │ Kafka
           ▼
    ┌──────────────┐
    │    Kafka     │
    │   (Topic)    │
    └──────┬───────┘
           │
      ┌────┴────┬──────┬─────────┐
      │         │      │         │
      ▼         ▼      ▼         ▼
┌──────────┐ ┌──────────┐ ┌──────────┐     ┌──────────┐
│  Solr    │ │  HDFS    │ │  New     │ ... │   Nth    │
│ Dispatcher │ │ Dispatcher │ │ Dispatcher │     │ Dispatcher │
└────┬─────┘ └────┬─────┘ └────┬─────┘     └────┬─────┘
     │            │            │                 │
     ▼            ▼            ▼                 ▼
┌─────────┐  ┌──────────┐ ┌──────────┐     ┌──────────┐
│  Solr   │  │   HDFS   │ │   New    │     │   Nth    │
│ (Index) │  │ (Storage) │ │(Dest)    │     │ (Dest)    │
└─────────┘  └──────────┘ └──────────┘     └──────────┘