Behavioral Changes

Previously, Cloudera Manager allows replication to cloud clusters even when the target Cloudera Manager on the cloud does not trust the TLS certificate from the source Cloudera Manager.

When you create a new Replication Peer in Cloudera Manager 7.13.2 SP1, the connection fails unless the target Cloudera Manager explicitly trusts the TLS certificate of the source Cloudera Manager. You must establish trust before creating new peers by following the procedures in Setting up SSL/TLS certificate exchange.

Impact on upgrades and backward compatibility

To maintain backward compatibility during upgrades, Cloudera Manager 7.13.2 SP1 automatically excludes existing Replication Peers from this TLS certificate validation requirement.

When upgrading to Cloudera Runtime 7.3.2.0, Cloudera Manager required administrators to manually reallocate and calculate cluster memory before executing the upgrade process. Failure to adjust these configurations manually in advance could lead to post-upgrade resource mismatches.

Starting with Cloudera Manager 7.13.2 SP1 (7.13.2.10000), the cluster upgrade command automatically handles and recalculates cluster memory allocations when upgrading to Cloudera Runtime 7.3.2 SP1. This automation removes the requirement for manual pre-upgrade memory adjustments.

Additionally, Cloudera Manager introduces a strict Hosts Memory Check validator to the pre-upgrade checklist. This validator automatically assesses host memory resources before the upgrade begins to ensure the underlying infrastructure can support the recalculated allocations.

In previous versions, the Cloudera Manager login user interface (UI) displayed the Remember Me checkbox by default. When users selected this option during login, Cloudera Manager granted them an extended, persistent session lasting up to two weeks. This allowed users to access the console without re-authenticating, even after closing their browsers or experiencing standard session timeouts.

To prevent unintended persistent sessions and improve security, Cloudera Manager now hides the Remember Me checkbox by default. Consequently, users no longer see this checkbox on the login screen, and the system enforces the standard 30-minute session timeout. Users must re-authenticate once their session expires.

To restore the checkbox to the login UI and allow the two-week persistent session, administrators must manually enable the session_remember_me parameter by navigating to Administration > Settings within the Cloudera Manager Server Configuration settings.

When you updated the Auto-TLS global truststore using the Admin Console or the updateGlobalTruststore API, uploaded certificates always replaced the existing global truststore. To add certificates without losing previously imported trust material, you had to export the current truststore, combine those certificates with new certificates in a single PEM file, and upload the combined file.

The Update Auto-TLS Truststore dialog and the updateGlobalTruststore API now support an optional append mode. Replace remains the default behavior and is unchanged when you do not select append or set the append parameter to false. When you select Append to existing truststore or set append to true, Cloudera Manager keeps the current truststore contents and adds the uploaded certificates after the existing CustomCert aliases instead of overwriting them. This lets you add certificates incrementally without exporting and recombining the current truststore contents.

For more information, see Updating the Auto-TLS Global Truststore.

Previously, the Create/Edit Ozone replication policy dialog box in the Cloudera Manager BDR UI did not provide options to configure inclusion filters, limiting the ability to specify exactly which resources should be replicated.

Now, new UI elements to add and remove inclusion filters are available on the Advanced tab of the Create/Edit Ozone replication policy dialog box, allowing for more granular control over Ozone replication tasks.

Previously, Ozone Prometheus did not support server-side TLS. Connections to its web UI and metric endpoints were unencrypted (HTTP).

Now, Ozone Prometheus supports server-side TLS, allowing you to configure specific TLS versions and cipher suites. TLS is automatically enabled if the ENCRYPT_ALL_PORTS feature flag is active. When enabled, external integrations (such as Grafana) must be updated to connect using HTTPS.

1. spark.ui.enabled=false: preventing initiation of an HTTP service that can be accessed from external hosts.
2. spark.io.encryption.keySizeBits=256: the default Spark keySizeBits has been increased from 128 to 256

In standard (non-FIPS) mode, Cloudera Manager relies on the JVM’s default cacerts truststore, which is in JKS format. This allows Cloudera Manager to automatically trust the default CA certificates shipped with the JDK and establish secure connections to external endpoints such as S3 or Cloudera repositories.

In FIPS mode, only FIPS-compliant keystore formats (such as BCFKS) are permitted. Because the default cacerts is in JKS format, Cloudera Manager skips loading it to prevent startup failures and instead uses the Cloudera Manager-provided truststore exclusively. This ensures consistent and reliable operation under FIPS compliance, but means that Cloudera Manager does not automatically trust certificates present only in the JVM's default cacerts.

As a result, connections to certain external endpoints (for example, public cloud services, S3, Cloudera download URLs) might fail unless their certificates are also present in the Cloudera Manager-provided truststore.

• hbase.rs.evictblocksonclose = HBase region server cache data blocks on read (Cache data blocks on read)
• hbase.block.data.cacheonread = HBase region server evict blocks of a file cache when the file is closed (Evict all blocks of a given file from the block cache when the file is closed)

Each service role ran with the File Descriptor (FD) limit you explicitly configured in Cloudera Manager, or with the default limit if you set none.

The new behavior allows administrators to increase the FD limit globally across all managed services by modifying the relevant supervisord service file or system.conf, regardless of individual role settings.

Cloudera Manager did not add default Apache Ranger policies that grant the atlas user permission to create, edit, or delete Kafka topics with the ATLAS_IMPORT_ prefix or to access the atlas_import consumer group.

Cloudera Manager adds default Apache Ranger policies so the atlas user can create, configure, alter, publish, and delete Kafka topics with the ATLAS_IMPORT_ prefix and can use the atlas_import consumer group for Atlas asynchronous import.

You could configure a component-specific Java home for Kafka, Schema Registry, Streams Messaging Manager (SMM), and Streams Replication Manager (SRM).

The component-level custom Java home configuration options are removed for Kafka, Schema Registry, SMM, and SRM. These services now use the host-level java_home configuration. If you previously set a component-specific Java home for any of these services, verify the host-level java_home setting after upgrading.