What's New in Apache Ranger

Learn about the new features of Apache Ranger in Cloudera Runtime 7.3.2.0, its service packs and cumulative hotfixes.

Cloudera Runtime 7.3.2.0:

The new features for Apache Ranger in Cloudera Runtime 7.3.2.0 include cumulative updates from previous releases. This version specifically incorporates features introduced in Cloudera Runtime 7.3.1.100 through 7.3.1.706. For a complete list, see New Features.

Support for Amazon S3-compatible object stores through RAZ

Support has been added for Amazon S3-compatible object stores through the Ranger Remote Authorization Service (RAZ).

Cloudera Base on premises defaults to HDFS and natively supports the Ozone object store. There was limited support for Amazon S3-compatible object stores with respect to executing workloads like Hive and Spark. Not all workloads were supported from an authorization perspective on Amazon S3-compatible object stores. The inconsistent policy framework created challenges for the Policy Administrator in terms of applying corporate policies to secure sensitive data. Managing data access across teams and individuals was an architectural challenge.

The Ranger RAZ resolves this challenge by using Apache Ranger policies to authorize access to Amazon S3-compatible object storage, similar to HDFS files. For details, see Access Control for Amazon S3-compatible object stores.

Ranger has been upgraded

Ranger has been upgraded from version 2.4.0 to 2.6.0, incorporating the latest fixes and improvements from the Ranger project while maintaining compatibility with existing Cloudera deployments.

Ranger HBase plugin optimizations

You can now enable column authorization optimization, wherein column authorization is skipped when a user is fully authorized for the column families. To enable this optimization, add the following Ranger service configuration for cm_hbase from Ranger UI: ranger.plugin.hbase.column.auth.optimized=true. The new configuration can lead to significantly better performance of multiget and multiput workloads, wherein thousands of columns may be accessed together. No HBase service restart is required to enable or disable this configuration.

When the optimization is enabled, there is a behavior change in auditing in Ranger. For more information, see Behavioral Changes in Apache Ranger.

Ranger RMS supports for multiple storage types

Starting with Cloudera Base on premises 7.3.2.0 release, RMS supports S3 storage in addition to HDFS and Ozone, allowing it to track mapping data for all these storage types simultaneously.

After the first full-synchronization run, RMS downloads mappings for tables and databases present in the Hive Metastore (HMS). These tables/databases could be located in S3, OZONE, and HDFS file systems. RMS will map the tables and databases with their respective storage locations and store them in the Ranger database with their associated service ID (cm_s3, cm_ozone, or cm_hdfs). When raz-s3-chained-plugin, ranger-ozone-plugin, or ranger-hdfs-plugin requests mappings, it only retrieves the mappings relevant to its service. Specifically, raz-s3-chained-plugin downloads mappings exclusively for tables/databases whose storage location is S3, ranger-ozone-plugin for Ozone, and ranger-hdfs-plugin for HDFS.

User's last login timestamp visibility

The Ranger Admin Web UI now displays the logged-in user's last login date and time on all pages.

Earlier, this information was only available under Ranger > Audits > Login Sessions.

Now the user's last login timestamp is persistently visible across all pages. For a user's initial login, the last login timestamp will not be displayed. Upon subsequent logins, the timestamp of the preceding successful login will be displayed.

Storage change for Ranger admin audit logs

Starting from Cloudera Runtime 7.3.2.0, Ranger admin audit logs are stored in the x_trx_log_v2 table in the Ranger database. In releases earlier than 7.3.2.0, Ranger admin audit logs were stored in the x_trx_log table in the Ranger database. Hence, if you upgrade to Cloudera Runtime 7.3.2.0 from any previous version and you want to retain your old data, you must migrate the Ranger admin audit logs from the x_trx_log table to the x_trx_log_v2 table.

For more information on how to migrate the data, see Migrating Ranger admin audit logs.

Back up ranger_audits Solr collection

When upgrading to Cloudera Runtime 7.3.2.0 and later releases that update the Ranger Audits Solr schema, Cloudera Manager runs an internal service command to apply the schema changes safely.

Although the command is designed to be non-destructive, Cloudera strongly recommends creating a backup of the Ranger Audits Solr collection before starting the upgrade. This ensures a quick restoration of audit data if anything goes wrong during the upgrade.

For more information, see Back up ranger_audits Solr collection.

Ranger mixed case group comparison

When Ranger Usersync is configured with case conversion and special character replacement using Regular Expression (regex), Ranger Usersync transforms the original user or group names from the source, for example, AD or LDAP, before storing them in the Ranger Admin database. Previously, if a Ranger plugin used the original name during authorization checks, the check failed because the Ranger Admin only recognized the transformed name.

This issue is now fixed. The fix is configurable at the plugin level using the ranger.plugin.<serviceType>.supports.name.transformation property, allowing users to enable or disable transformation based on their environment needs. For more information, see Handling inconsistent username and group name conventions for consistent authorization.

ranger.plugin.hive.urlauth.filesystem.schemes configuration with default value of hdfs:

The default value of the ranger.plugin.hive.urlauth.filesystem.schemes configuration is hdfs:,file:,wasb:,adl:. When the ranger.plugin.hive.urlauth.filesystem.schemes configuration includes hdfs: as a default filesystem scheme in both HMS and HiveServer2, and you perform a CREATE EXTERNAL TABLE operation with a LOCATION clause, if both the Ranger Hive and HDFS plugins are enabled, the Ranger Plugin Authorizer performs authorization checks on all files within the target directory. This results in performance degradation that scales up linearly with the number of files.

The default value of the parameter remains unchanged, but a warning message has been added for the user. For more information, see Hive authorizer URL policy with hdfs default value.

Added validation for whitespace in Ranger policy names

Ranger Admin now validates and handles leading and trailing whitespace in policy names and related properties (for example, db_name vs


                db_name

) created through the Ranger API. Policies that contain unintended whitespace are detected and normalized so they no longer appear inconsistent between the API and the Ranger Admin web UI, helping prevent confusing behavior and reducing issues for application teams.

Bulk delete policies using policy name prefix

Added a Ranger REST API endpoint that supports bulk deletion of policies by policy name prefix (wildcard). Administrators can now delete multiple policies in a single request by specifying a service name and a policy name prefix (for example, JAMES*), improving operational efficiency over deleting policies one by one.

Support SASL bind for Ranger Usersync with AD/LDAP

Introduced support for SASL GSSAPI authentication in Ranger Usersync when connecting to AD/LDAP. This allows customers to avoid using simple bind credentials and mitigates performance and reliability issues observed with SSSD on RHEL 8.8 (for example, incomplete getent results with enumerate=true).

Ranger RAZ service-admin delegation support

Ranger RAZ now supports delegation for users with service-admin privileges. When making authorization calls to RAZ, users defined in the Ranger service configuration as service.admin.users or belonging to groups in service.admin.groupscan authorize access on behalf of other users. Requests from these service-admin users are also trusted for details such as the resourceOwner, improving support for administrative and service-level access workflows.

RAZ to support authorization for CAII service on Cloudera Base on premises

In Cloudera Base on premises 7.3.2.0, Ranger RAZ now supports the Cloudera AI Inference (CAII) service for authorization. During initialization, Ranger automatically creates the CAII service definition and a corresponding service instance, similar to other RAZ‑managed services (for example, cm_hive and cm_s3). RAZ has been enhanced to authorize access to CAII resources and to honor service.admin.users and service.admin.groups so that designated service administrators can authorize access on behalf of other users.

Improved handling of Kafka super users in Ranger Kafka plugin

The Ranger Kafka authorizer now automatically parses the Kafka super.users configuration property and adds those users to the plugin’s super-user list. This allows Strimzi and other deployments that rely on super.users (for example, cluster operator and broker users) to have the expected unrestricted access to Kafka resources without requiring duplicate super-user configuration in Ranger.

Ranger Usersync LDAP referral handling improved

In Cloudera Runtime 7.3.2.0, the default value of the Ranger Usersync LDAP referral configuration has been changed from ignore to follow (ranger.usersync.ldap.referral=follow). This enables Ranger Usersync to follow LDAP referrals during group searches, which helps prevent

javax.naming.PartialResultException: Unprocessed Continuation
                Reference(s)

errors commonly seen with Active Directory LDAP and reduces the need for relying on the AD Global Catalog for referral resolution.

IP-based access control for policies

Ranger now supports IP-based access control across additional services by using context enrichers and policy conditions. Administrators can configure IP location data files, register the RangerFileBasedGeolocationProvider context enricher, and define IP-based policy conditions (for example, accessed-from-ip) to allow or deny access based on client IP ranges. This capability is not enabled by default and must be explicitly configured, following the steps described in the Apache Ranger Geo-location based policies documentation.

Improved REST API responses for policy?policyNamePartial

Ranger policy REST API responses for policy?policyNamePartial have been enhanced to optionally include policy metadata fields such as createTime and updateTime. These meta attributes are now configurable for retrieval, allowing administrators to access policy creation and modification timestamps directly from the public v2 policy API when enabled.

Ranger Swagger API usability improvement

The Ranger /service/xusers/users Swagger API now supports the optional query parameters syncSource and userRole. These parameters are exposed as fillable fields in Swagger to make it easier to construct complex user search requests (for example, filtering users by sync source such as Unix or LDAP/AD, or by role such as admin), especially for less technical users and environments with large user populations.

Improved authzmigrator script

Improved the authz-export.sh (authzmigrator) script so it no longer relies on a hard-coded Cloudera parcel path and JDBC driver. The script now uses the configured Cloudera Manager parcel directory (via SENTRY_HOME) and automatically selects the appropriate JDBC driver for the underlying database, preventing

NoClassDefFoundError:
                javax/jdo/JDOHelper

and making it more robust in environments with custom parcel layouts and non-default DB flavors.

Downlist the public group from Select Group option in New Policy page

To reduce the risk of accidentally assigning the Public group when creating a new Ranger policy, the Tab key no longer selects a group in the Select Group field on the New Policy page. Pressing Tab now only moves focus to the next field as expected, while the Enter key remains the standard way to confirm a group selection. This change significantly lowers the chance of unintended Public group assignment without impacting normal group selection behavior.

Delete Ranger RAZ access logs based on max number of files

To prevent Ranger RAZ access logs from filling up disk space on busy environments, Ranger RAZ now supports log rotation based on a configurable maximum number of access log files. Previously, access logs could only be rotated based on age (with a default of 15 days), which could still allow logs to exhaust the volume on high-activity clusters. With this enhancement, administrators can limit the number of retained Ranger Raz access log files, helping ensure Cloudera Manager and other services remain available even under heavy load.

Ranger access audit option to exclude resource

Improved Ranger access audit filtering to support excluding specific resources by name.You can now use an Exclude Resource Name filter in the Ranger Access audit UI so that audit searches can omit events for specified resources, leveraging existing backend Solr support for these exclusions.

Included authz_export.tar.gz for Sentry to Ranger migration with Cloudera Manager package

For CDH‑to‑CDP upgrades that involve Sentry‑to‑Ranger migration, the authz_export.tar.gz package is now bundled with the Cloudera Manager installation, in the same location as authz-ingest.zip. This eliminates the need to contact Cloudera support to obtain the export archive from internal sources and simplifies authorization policy migration.

Ranger Admin logs to show the local timezone rather than UTC

Ranger Admin now records log timestamps in the local system timezone of the host instead of UTC. This aligns Ranger Admin logs with other Ranger components (such as UserSync and TagSync) and removes the need for manual log4j configuration, making troubleshooting and correlation with other system logs easier.

Cloudera Manager now sanitizes cluster names

Cloudera Manager now sanitizes cluster names that contain spaces when creating and evaluating Ranger plugin repositories that use the UNIQUE_PER_SERVICE naming strategy. Spaces in the derived Ranger repository (service) name are automatically replaced with underscores (_), ensuring compatibility with the Ranger constraint introduced in RANGER-2808 that disallows spaces in service names.

Improved Ranger Admin Diagnostic collection command from Cloudera Manager scripts

In Cloudera Manager 7.13.2.0, the Ranger Admin diagnostic collection command has been enhanced. A new configuration option, ranger.admin.diag.metrics.collection.type, allows you to control which types of Ranger metrics are collected during the Cloudera Manager diagnostics command. This helps avoid long‑running Ranger Admin metrics collection (for example, cases where collection could exceed 40 minutes and cause the Cloudera Manager diagnostic command to stop) by letting you limit or skip specific metrics types as needed.

Updated Ranger RMS, TAGSYNC, and USERSYNC CSDs

Updated Ranger RMS, TAGSYNC, and USERSYNC Cloudera Service Descriptors (CSDs) to support the new Ranger RMS high availability (HA) implementation used by the ranger-common-ha module. The RMS server and tagsync/usersync service port configs are now managed as first‑class CSD properties rather than via safety valves, improving HA configuration consistency and upgrade handling.

Cloudera Manager updates Ranger plugin service repositories with the correct cluster configurations

Cloudera Manager now updates Ranger plugin service repositories with the correct cluster configurations for test connection and resource lookup. For Ranger plugins on HBase, Knox, Atlas, and Ozone, Cloudera Manager automatically calculates and populates the required URLs, principals, and related settings instead of creating repositories with default, nonfunctional values. This reduces configuration errors and addresses frequent “Test connection” and lookup failures seen in customer deployments.

Enforce truststore configuration when Ranger plugin is enabled with Ranger admin SSL

When the Ranger plugin is configured to use Ranger Admin over SSL, Cloudera Manager now enforces truststore configuration for the plugin services. If the truststore settings are missing, the Ranger Plugin Services page displays a validation warning, helping prevent plugin sync failures caused by an unconfigured truststore.

Improved control of Ranger audit spooling to prevent disk exhaustion

Added Cloudera Manager configuration options for the Ranger plugins to control audit file spooling, including the spool file rollover interval and the maximum number of archived spool files. These settings are now exposed centrally for HDFS and Solr Ranger audits, reducing the risk of /var/log filling up when the audit destination is unavailable and eliminating the need for per-service safety‑valve configuration.

Ranger audits collection creation reliability improved

Updated the Ranger audit configuration so that the ranger.audit.solr.time.interval setting now uses a 60-second (60000 ms) delay between retries when creating the ranger_audits collection in Solr, improving reliability in environments where Solr starts later than Ranger.