Apache Ranger Tutorial: Centralized Security Administration (2026)

Published: August 20, 2026 | Category: Big Data | Reading time: ~15 min

Apache Ranger provides centralized authorization and auditing for the Hadoop ecosystem. After configuring Ranger for clusters handling sensitive data under regulatory compliance, I appreciate how it enforces fine-grained access policies across HDFS, Hive, Kafka, and other services from a single administrative console.

This tutorial covers Ranger's policy model, plugin architecture, user/group management, row and column-level security, and integration with Hadoop services for centralized access control.

📖 Table of Contents

Ranger Architecture and Plugin Model
Policy Model and Resource Definitions
Row-Level and Column-Level Security
Kafka and HBase Policies
Auditing and Compliance
Service Integration and Plugin Setup

Ranger Architecture and Plugin Model

Ranger consists of a central Admin Web UI, a Policy Administration Point, and Policy Enforcement Points (PEPs) deployed as plugins in each Hadoop service. The Admin UI is the single pane for managing policies. Policy changes are pushed to plugins in near-real-time via a policy synchronization mechanism.

Each service plugin (HDFS, Hive, Kafka, etc.) intercepts access requests and checks against locally-cached policies. Policies are cached in the plugin process, so authorization decisions are fast (no network calls for every request). Changes propagate within seconds via ZooKeeper notifications.

# Ranger Admin configuration
# ranger-admin-site.xml

  ranger.admin.bootstrap.enabled
  true


  ranger.admin.repository.config.xa.provider.url
  https://ranger-admin:6182


# Ranger User Sync
# ranger-ugsync-site.xml

  ranger.usersync.ldap.url  ldap://ldap-server:389


  ranger.usersync.ldap.basedn
  dc=example,dc=com


# Start Ranger
$ ranger-admin start
$ ranger-usersync start

Policy Model and Resource Definitions

Ranger policies define who can do what on which resources. Policies are organized by service (HDFS, Hive, Kafka), repository, and resource type. Resources include HDFS paths, Hive databases/tables/columns, Kafka topics, and HBase tables/columns. Each policy specifies conditions (user, group, IP) and permissions (read, write, execute).

Policy evaluation follows a deny-overrides model: if any policy denies access, the request is denied regardless of other policies. This ensures that restrictive policies always take precedence.

# HDFS Policy: Allow analysts to read specific directories
{
  "service": "hadoop_dev",
  "name": "analyst_hdfs_read",
  "isEnabled": true,
  "resources": {
    "path": {
      "values": ["/data/analytics/*"],
      "isRecursive": true
    }
  },
  "policyItems": [{
    "accesses": [{"type": "read", "isAllowed": true}],
    "users": ["analyst1", "analyst2"],
    "groups": ["data-analysts"]
  }],
  "denyPolicyItems": [{
    "accesses": [{"type": "read", "isAllowed": true}],
    "users": ["contractor1"],
    "delegateAdmin": false
  }]
}

# Policy evaluation: deny > allow > mask > audit

Row-Level and Column-Level Security

Ranger provides row-level filtering and column-level masking for Hive tables. Row-level policies filter rows based on user attributes — a user sees only rows where a condition is true. Column-level masking transforms column values (partial mask, hash, null) based on user permissions.

These features enable multi-tenant data sharing: a single Hive table can be accessed by multiple teams, each seeing only their authorized rows and columns. This eliminates the need to create separate tables for each security boundary.

# Row-level filter: users see only their department's data
# Ranger Policy for Hive table analytics.sales
{
  "service": "hive_prod",
  "name": "sales_row_filter",
  "resources": {
    "database": {"values": ["analytics"]},
    "table": {"values": ["sales"]},
    "column": {"values": ["*"]}
  },
  "rowFilterPolicyItems": [{
    "users": ["sales_team"],
    "groups": ["sales"],
    "filterExpr": "department = 'sales'"
  }],
  "dataMaskPolicyItems": [{
    "users": ["hr_team"],
    "dataMaskInfo": {
      "dataMaskType": "PARTIAL_MASK",
      "dataMaskValues": ["first5", "***"]
    },
    "dataMaskInfo": {
      "column": "ssn",
      "dataMaskType": "PARTIAL_MASK",
      "dataMaskValues": ["first5", "***"]
    }
  }]
}

Kafka and HBase Policies

Ranger's Kafka plugin controls topic-level access: produce, consume, configure, and describe operations. Policies can restrict which topics a user can read/write and which consumer groups they can use. This is critical for multi-tenant Kafka environments where different teams share the same cluster.

For HBase, Ranger controls table, column family, and column-level access. Policies distinguish between read, write, create, and admin operations. Combined with HBase's cell-level security, this provides defense-in-depth for sensitive data.

# Kafka Policy: restrict topic access
{
  "service": "kafka_prod",
  "name": "team_a_kafka_access",
  "resources": {
    "topic": {
      "values": ["team_a_events"]
    },
    "consumer-group": {
      "values": ["team_a_consumer"]
    }
  },
  "policyItems": [{
    "accesses": [
      {"type": "publish", "isAllowed": true},
      {"type": "consume", "isAllowed": true},
      {"type": "configure", "isAllowed": true}
    ],
    "users": ["team_a_producer", "team_a_consumer"]
  }]
}

# HBase Policy
{
  "service": "hbase_prod",
  "name": "finance_hbase_read",
  "resources": {
    "table": {"values": ["transactions"]},
    "column-family": {"values": ["account"]},
    "column": {"values": ["balance", "history"]}
  },
  "policyItems": [{
    "accesses": [{"type": "read", "isAllowed": true}],
    "users": ["finance_analyst"]
  }]
}

Auditing and Compliance

Ranger logs every authorization decision — allowed and denied — to an audit trail. Audit logs include user, resource, action, time, and result. These logs are essential for compliance (SOX, HIPAA, GDPR) and security investigations. Audit logs can be exported to Solr, Elasticsearch, or HDFS for long-term retention.

The audit dashboard in Ranger Admin shows real-time access patterns, denied requests, and policy changes. This visibility helps identify unauthorized access attempts and policy misconfigurations.

# Audit configuration
# ranger-audit.xml

  xasecure.audit.is.enabled
  true


  xasecure.audit.destination.solr
  true


  xasecure.audit.destination.solr.url
  http://solr-host:8983/ranger_audits


  xasecure.audit.destination.hdfs
  true


  xasecure.audit.destination.hdfs.dir
  hdfs:///ranger/audit


# Query audit logs
curl -u admin:admin \
  http://ranger-admin:6182/service/public/v2/api/audit?startDate=2026-01-01T00:00:00Z&endDate=2026-01-02T00:00:00Z

# Audit event fields: user, repo, resource, action, result, reason, timestamp

Service Integration and Plugin Setup

Ranger plugins are installed in each Hadoop service's JVM process. The HDFS plugin runs in NameNode, Hive plugin in HiveServer2, Kafka plugin in Brokers. Each plugin loads policies from Ranger Admin on startup and caches them locally. Policy changes propagate via ZooKeeper notification.

Configuration for each plugin is in ranger-{service}-site.xml. The plugin communicates with Ranger Admin over HTTPS using the ranger.truststore.password for certificate validation.

# HDFS plugin configuration
# ranger-hdfs-site.xml

  ranger-hdfs-plugin.enabled
  true


  ranger-hdfs-plugin.service.remote.admin.url
  https://ranger-admin:6182


  ranger-hdfs-plugin.service.remote.admin.username  ranger_admin


# Hive plugin configuration
# ranger-hive-site.xml

  ranger-hive-plugin.enabled
  true


# Kafka plugin
# ranger-kafka-plugin.xml

  ranger-kafka-plugin.enabled
  true


# Restart services after enabling plugins
$ service hdfs restart  # NameNode gets HDFS plugin
$ service hive restart  # HiveServer2 gets Hive plugin

Frequently Asked Questions

What is the difference between Ranger and Sentry?

Ranger is the successor to Sentry. Ranger provides a central admin UI, policy versioning, and broader service support. Sentry only handled Hive and Impala. New deployments should use Ranger exclusively.

How does Ranger handle multi-tenancy?

Ranger policies can restrict access by user, group, and conditions (department, project). Combined with Hive row/column-level security, Ranger enables multiple teams to share cluster resources safely.

Can Ranger manage access to cloud storage (S3, GCS)?

Ranger's S3 plugin (for EMR) and HDFS plugin (which covers HDFS-compatible storage) can manage access to cloud storage. Policies use path-based resources similar to HDFS policies.

How does Ranger enforce policies in real-time?

Plugins cache policies locally and evaluate access in-process — no network calls per request. Policy changes propagate via ZooKeeper within seconds. This ensures sub-millisecond authorization decisions.

Originally published on Ayodhyyya. Last updated June 1, 2026.