Cloudera Docs

What's New in Cloudera Manager

Learn about the new features and changed behavior of Cloudera Manager in Cloudera Manager 7.13.2 and its cumulative hotfixes.

You must be aware of the additional functionalities and improvements to features of Cloudera Manager in Cloudera Manager 7.13.2 and its cumulative hotfixes. Learn how the new features and improvements benefit you.

Cloudera Manager 7.13.2 introduces new features and includes all cumulative hotfixes from 7.13.1.100 through 7.13.1.700. For a comprehensive record of all updates in Cloudera Manager 7.13.1.x, see What's New in Cloudera Manager 7.13.1.x.

Cloudera Manager 7.13.2 SP1 (7.13.2.10000)

TLS 1.3 Protocol Support

Cloudera Manager 7.13.2 SP1 and Cloudera Runtime 7.3.2 SP1 introduce support for the Transport Layer Security (TLS) 1.3 protocol across managed cluster components and service endpoints.

By default, Cloudera Manager hides advanced TLS configurations in the Admin Console, so you must enable the CMF_FF_TLS_ADVANCED_CONTROL and CMF_FF_ENCRYPT_ALL_PORTS feature flags in /etc/default/cloudera-scm-server and restart the Cloudera Manager server process to make these controls visible in the Cloudera Manager UI.

Once you enable these feature flags, you can configure protocol policies (TLS 1.3 exclusively, TLS 1.2 exclusively, or a dual TLS 1.2 and TLS 1.3 fallback mode) through the Cloudera Manager UI under Administration > Settings(Supported SSL/TLS versions) or through the API.

For information about enabling advanced TLS controls, system prerequisites, global cipher management, and deployment limitations, see Transport Layer Security Support and Custom Protocol Configuration.

Cloudera completely deprecates legacy insecure protocol combinations (including TLS 1.0, TLS 1.1, and SSLv2Hello) and disables them when you activate advanced controls.
TLS Encryption support for Cloudera Management Service

Starting in Cloudera Manager 7.13.2 SP1 (7.13.2.10000), you can configure server-side TLS encryption for Cloudera Management Service roles. Cloudera Manager controls TLS for these roles through advanced encryption feature flags, so Cloudera Manager does not activate TLS automatically upon upgrade.

To enable TLS across Cloudera Management Service roles (including Service Monitor, Event Server, Alert Publisher, Reports Manager, and Host Monitor), you must set CMF_FF_ENCRYPT_ALL_PORTS=true and CMF_FF_TLS_ADVANCED_CONTROL=true in /etc/default/cloudera-scm-server, and then restart the Cloudera Manager Server. Once activated, administrators can customize or adjust individual role configurations directly from the Cloudera Manager Admin Console. For more information, see Configuring TLS/SSL for Cloudera Management Service

TLS Encryption support for Hive Metastore
You can now configure Transport Layer Security (TLS) properties directly in the Cloudera Manager configuration page for the Hive Metastore Server (HMS). This feature provides secure connections between the HMS and Hive Metastore clients, such as HiveServer2, Impala daemons (coordinator and catalogd), Kudu, Ranger RMS, and Oozie.
The following properties are used to configure the secure connection when the hive.metastore.use.SSL property is set to true:
  • hive.metastore.use.SSL — Enables TLS support on both the client side and the server side.
  • hive.metastore.keystore.path — Specifies the path to the keystore file on the HMS server side.
  • hive.metastore.keystore.password — Specifies the password for the keystore file on the HMS server side.
  • hive.metastore.keystore.type — Specifies the format of the keystore file on the HMS server side.
  • hive.metastore.truststore.path — Specifies the path to the truststore file on the client side.
  • hive.metastore.truststore.password — Specifies the password for the truststore file on the client side.
  • hive.metastore.truststore.type — Specifies the format of the truststore file on the client side.
  • hive.metastore.include.protocols property — Restricts connections to specific, high-security TLS protocol versions on the HMS server side.
  • hive.metastore.include.ciphersuites property — Enforces strong cryptographic algorithms during handshake negotiations between the server and the client.
Python 3.12 Support for Cloudera Manager 7.13.2 SP1 and Cloudera Runtime 7.3.2 SP1

Cloudera Manager 7.13.2 SP1 and Cloudera Runtime 7.3.2 SP1 introduce support for Python 3.12 alongside Python 3.11, while maintaining backward compatibility for managed clusters.

The Cloudera Manager Agent automatically selects the highest available Python version (preferring Python 3.12 over Python 3.11) to execute internal operations. When managing cluster roles, Cloudera Manager automatically resolves the highest supported Python version for each managed cluster's specific release version, ensuring complete backwards compatibility with existing clusters without requiring changes on older managed hosts. For detailed host installation procedures and Python compatibility matrices, see Installing Python 3.12 standard package on supported operating systems and Python compatibility across Cloudera Runtime releases.

FIPS 140-3 Compliance Support in Replication Manager

Starting with Cloudera Manager 7.13.2 SP1 (7.13.2.10000) and Cloudera Runtime 7.3.2.10000 (SP1), Replication Manager supports replication workloads in FIPS 140-3 compliant environments with a combined fallback configuration of TLS 1.2 and TLS 1.3.

Replication Manager automatically inherits FIPS 140-3 compliance from the underlying Cloudera Manager and cluster-level security settings. Administrators do not need to configure a separate or dedicated setup workflow within Replication Manager.

Supported Workloads:
Replication Manager supports FIPS 140-3 compliant replication for the following replication types:

  • HDFS Replication

  • Hive Replication

  • Iceberg Replication (DMX)

  • Ranger Replication

  • Atlas Replication

  • HBase Replication (Native)

Migrating Replication Workloads from FIPS 140-2 to FIPS 140-3
Replication Manager now supports replicating data from legacy source clusters running FIPS 140-2 to target clusters running FIPS 140-3 on 7.3.2 SP1 across the following supported release baselines:
Source Cluster (FIPS 140-2) Target Cluster (FIPS 140-3) Supported Workloads
  • Cloudera Runtime 7.1.9 SP1 CHF15
  • Cloudera Manager 7.11.3.27 / .37
  • JDK 11
  • RHEL 8.10
  • Cloudera SASL Provider
  • Cloudera Runtime 7.3.2 SP1 (7.3.2.10000)
  • Cloudera Manager 7.13.2 SP1 (7.13.2.10000)
  • JDK 17
  • RHEL 9.6
  • TLS 1.2 + TLS 1.3
 HDFS, Hive, Ranger, HBase
  • Cloudera Runtime 7.1.9 SP2
  • Cloudera Manager 7.13.1.800
  • JDK 11
  • RHEL 8.10
  • Cloudera SASL Provider
  • Cloudera Runtime 7.3.2 SP1 (7.3.2.10000)
  • Cloudera Manager 7.13.2 SP1 (7.13.2.10000)
  • JDK 17
  • RHEL 9.6
  • TLS 1.2 + TLS 1.3
 HDFS, Hive, Iceberg, Ranger, Atlas, HBase
Technical Preview: HDFS to Ozone migration through unified Replication Manager app service
Deployment and configuration
To create replication policies in the Replication Manager UI, you must first complete the required setup tasks. You must contact your Cloudera Account Team or Cloudera Support to perform or get assistance with any of the following tasks:
  • Service deployment: Deploying and configuring the Replication Manager (RM) service using the Replication Manager parcel in Cloudera Manager.
  • Adding the service: Adding the RM service to your environment once the parcel is installed.
  • Cluster registration: Registering both your source and target clusters within the environment so they can communicate with the new service.
After Cloudera Support or your Cloudera account team assists you to deploy, add the service, and register your clusters, you can view, create, and manage your replication policies seamlessly across both the traditional Cloudera on-premises Replication Manager and the new Replication Manager service UI.
Creating an HDFS to Ozone migration
In this Technical Preview, HDFS to Ozone migrations are executed using Cloudera Migration Assistant (CMA) 4.1.1 with the Replication Manager service operating as the underlying engine. For setup and execution steps, refer to the Integrating Cloudera Replication Manager documentation.
Support for Monitoring Hive ACID Incremental Job run details
Starting from Cloudera Manager 7.13.2 SP1 (7.13.2.10000), you can monitor incremental job runs in real time for Hive ACID replication policies directly using the Progress section on the Replication Policies page.

This update introduces real-time metrics, such as the last executed write transaction, source and target commit timestamps, and replication latency. With these metrics, you can verify point-in-time consistency and track Recovery Point Objectives (RPOs). For more information, see Managing and monitoring Hive ACID table replication policies.

Path inclusion support using regular expressions in Ozone replication policies
Cloudera Manager 7.13.2 SP1 introduces path inclusion capabilities for Ozone replication policies using regular expressions.

When creating or editing an Ozone replication policy under the Advanced tab, you can now use the Add Inclusion option to specify comma-separated regular expressions. Replication Manager will automatically replicate only the subdirectories or files from the source cluster that match one or more of your specified expressions.

The Advanced tab now features UI options to add and remove inclusion filters for targeted replication.

Mandatory Cluster Registration and V2 License Support

Starting with Cloudera Manager 7.13.2 SP1 (7.13.2.10000) and Cloudera Runtime 7.3.2 SP1, Cloudera introduces support for Version 2 (V2) licenses and enforces mandatory Cluster Registration for all managed clusters alongside the transition from Version 1 (V1) to Version 2 (V2) license keys. Applying a V2 license key or creating a new cluster requires registering each deployment to associate your environments with your software entitlements.

This process validates your deployments against your software entitlements, provides compliance visibility directly in the Cloudera Manager Admin Console, and optimizes license resource tracking across connected and air-gapped deployments.

Key policy details and capabilities

  • Version 2 License Key Support: Applying a V2 license key enables the new Cluster Registration Status page in the Cloudera Manager Admin Console.

  • Online Registration (Connected Environments): Cloudera Manager automatically (or through a single click on the Register button) registers and re-registers all managed clusters directly with Cloudera licensing servers when you apply a V2 license file.

  • Offline Registration (Air-Gapped Environments): Air-gapped environments perform offline bulk cluster registration using a two-way JSON file exchange. Administrators export a non-sensitive JSON package from Cloudera Manager, process and validate it in Cloudera Account 360, and import the signed confirmation package back into Cloudera Manager.

  • 60-Day Registration Grace Period: Cloudera Manager grants a 60-day grace period that begins on the exact date you create a cluster or apply a V2 license key in Cloudera Manager (not when Cloudera issues the license file).

  • Locked State Compliance Enforcement: If you do not register a cluster within the 60-day grace period, or if you apply a V2 license to an existing cluster after its 60-day period ends, Cloudera Manager places the cluster into a Locked state:

    • Running data workloads continue to process data normally.

    • You cannot start or restart clusters, services, or roles.

    • You cannot save or deploy configuration changes across the cluster.

    • Cloudera Manager locks administrative management features in the Web Console until you complete registration.

  • License Re-Registration: Applying a new or renewed V2 license key requires you to re-register all connected active clusters. Connected environments process this action automatically, whereas air-gapped environments require a manual bulk update.

  • Cluster Deregistration: Deleting a cluster makes it available on the Cluster Deregistration page, allowing administrators to deregister decommissioned clusters and immediately release license entitlements on the Cloudera license server for reuse across other deployments.

Required Action
Upon upgrading to Cloudera Manager 7.13.2 SP1 (7.13.2.10000) and applying a V2 license key, administrators must complete the initial registration process for all existing and newly created clusters:
  • For Connected Clusters: Ensure the Cloudera Manager Server maintains outbound HTTPS connectivity to Cloudera licensing endpoints. When you apply the V2 license file, Cloudera Manager automatically connects to the registration server to validate entitlements and complete registration. Alternatively, click the Register button to complete the process.

  • For Air-Gapped Clusters: Cloudera Manager uses a secure, two-way file exchange to register environments without direct internet access. Go to Administration > License in Cloudera Manager and use the Bulk Cluster Key Migration workflow to generate a registration JSON package. Export this package containing non-sensitive cluster identifiers, upload and validate it on Cloudera Account 360 using an internet-connected device, and import the resulting signed confirmation package back into Cloudera Manager.

For detailed procedures on online registration, offline bulk registration, and deregistering deleted clusters, see Registering and Deregistering Clusters in Cloudera Manager.

Cloudera Manager 7.13.2 CHF1 (7.13.2.100)

Support for CDP Private Cloud Base 7.1.9 SP2

Cloudera Manager 7.13.2 CHF1 (7.13.2.100) now supports managing clusters running Cloudera Runtime 7.1.9 SP2. You can perform new installations, upgrades, and management tasks for Cloudera Runtime 7.1.9 SP2 using this release of Cloudera Manager.

Cloudera Manager 7.13.2

Dual-Stack Support: IPv4 and IPv6 Address Visibility
Cloudera Manager now displays both IPv4 and IPv6 addresses for hosts in clusters where nodes are configured with dual-stack networking.

For more information, see IPv6 Support and Dual-Stack Configuration.

Python support for Cloudera Manager 7.13.2

Cloudera Manager 7.13.2 now supports only Python 3.11 version, when used in combination with Cloudera Runtime 7.3.2, 7.3.1.500 or higher versions, and 7.1.9 SP1 CHF11 or higher versions. For more information, see Installing Python 3.

Ubuntu 24.04 support for Cloudera Manager 7.13.2

Starting with the Cloudera Manager 7.13.2.0 release, Cloudera Manager provides support for Ubuntu 24.04. This update ensures seamless compatibility with Ubuntu version 24.04, offering greater flexibility and platform options.

Ubuntu 24.04 supports only the Python 3.11 version in the Cloudera Manager 7.13.2 release.

Managing Service Restarts on Ubuntu 24.04:

Overriding needrestart Automatic Restart Behaviour

Ubuntu 24.04 (Noble Numbat) introduced a significant change to the default behavior of the needrestart utility. By default, needrestart is now configured to automatically restart services any time apt updates underlying libraries (for example, libssl).

This behaviour is designed to apply security patches to running processes immediately. However, this can cause unplanned downtime for services like cloudera-scm-server.service (the Cloudera Manager Server).

To ensure service stability and to control all restarts, you can disable this automatic behaviour on all production Ubuntu 24.04 hosts. You can use multiple approaches to achieve this, as outlined in the Ubuntu Community Discourse: `needrestart` changes in Ubuntu 24.04: service restarts.

SLES 15 SP6 support for Cloudera Manager

Starting with the Cloudera Manager 7.13.2.0 release, Cloudera Manager provides support for SLES 15 SP6.

SLES 15 SP6 supports only the Python 3.11 version in the Cloudera Manager 7.13.2 release.

Kafka protocol and metadata version is set automatically during upgrades
When upgrading Kafka, Cloudera Manager now automatically sets the inter.broker.protocol.version property for ZooKeeper-based clusters and the metadata.version property for KRaft-based clusters. You no longer need to manually set these properties to the current protocol or metadata version before an upgrade. This feature is only available when upgrading to Cloudera Runtime 7.3.2 or higher.

After the upgrade, clearing these properties remains a manual task. However, in Cloudera Runtime 7.3.2 and higher, both inter.broker.protocol.version and metadata.version are now available for direct configuration in Cloudera Manager > Kafka > Configuration. The label names of the properties are Kafka Inter-Broker Protocol Version and Kafka Metadata Version. This means you can set or clear these properties directly from the UI, without needing to use advanced configuration snippets.

Enhancements to Iceberg replication policies in Cloudera Replication Manager
The following changes are available for Iceberg replication policies in Cloudera Replication Manager:
  • Added the following options to use during the Iceberg replication policy creation process:
    • JVM Options for Export –- You can enter comma-separated JVM options to use for the export process during the Iceberg replication policy run.
    • JVM Options for XFer –- You can enter comma-separated JVM options to use for the transfer process during the Iceberg replication policy.
    • JVM Options for Sync –- You can enter comma-separated JVM options to use for the sync process during the Iceberg replication policy.
    • Run as Username on Source –- You can enter the username if the peer cluster is configured with a different superuser. Ensure that the user is in the supergroup group on the HDFS NameNode host of the source cluster. This username acts as a proxy during the replication policy run.
  • Iceberg replication policies can replicate V1 and V2 Iceberg tables created using Hive.
  • You can replicate Iceberg tables stored on Ozone storage between Ozone buckets only using Iceberg replication policies. Complete the mandatory requirements before replicating the Iceberg tables stored in Ozone, and then configure the Source Storage Filter and Location Mapping options as required during the Iceberg replication policy creation process.
Unified Replication Manager App
You can deploy Unified Replication Manager App as a service in Cloudera Manager. You can manage this service as any other service in Cloudera Manager. You can create and manage HDFS, Hive external tables, and Ozone replication policies as well as HDFS and HBase snapshot policies in the Replication Manager service UI. For more details, contact your Cloudera Account Representative to access this feature.
Navigator Encrypt installed using Cloudera Manager
In Cloudera Runtime 7.3.2.0 and higher releases, the new Navigator Encrypt parcel centralizes the entire lifecycle management within Cloudera Manager. Previously, Navigator Encrypt required manual, host-by-host RPM installation and configuration. Administrators can now manage the installation, configuration, and upgrade of Navigator Encrypt across all cluster hosts directly from the Cloudera Manager interface. This new approach provides a significant improvement in usability, streamlining ongoing maintenance and lifecycle management.
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.
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.
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.
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.
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.

Added new HDFS Canary health check timeout configuration
A new configuration option, hdfs_canary_timeout, has been introduced to allow users to tune the timeout duration for the HDFS Canary health check. By default, this timeout is set to 30 seconds.
Increased the HDFS DataNode block count alert threshold
In Cloudera Manager 7.13.2.0, the default warning threshold for the number of blocks on an HDFS DataNode (datanode_block_count_thresholds) has been increased from 1 million to 4 million blocks.
Added Knox Proxyuser configuration parameters for Ozone Recon
Two new configuration parameters have been added to the Ozone Recon role to improve Knox integration:
  • ozone.recon.http.auth.proxyuser.knox.hosts
  • ozone.recon.http.auth.proxyuser.knox.groups

Both parameters default to *.