Behavioral Changes in HBase

Cloudera Runtime 7.3.2.10000 SP1

Summary: HBase enforces FIPS 140-3 compliant cryptographic standards

Previous behavior:

HBase used the default Java Cryptography Extension (JCE) provider, which permitted non-FIPS-compliant cryptographic algorithms. Deployments in FIPS-restricted environments had no platform-level enforcement, requiring manual configuration to restrict algorithm usage. TLS cipher suites and authentication token hashing were not validated against FIPS 140-3 requirements, which could result in failures during cryptosense compliance audits.

New behavior:

HBase is updated to use only FIPS 140-3 approved cryptographic algorithms. When the cluster operates in FIPS mode, non-compliant algorithms are disabled across all HBase services, including the HBase Controller (formerly known as HBase Master) and RegionServers. Only FIPS 140-3 approved TLS cipher suites are accepted for client connections and inter-service communication; non-compliant cipher suites are automatically excluded.

In version 7.3.2.10000, you might observe substantial performance degradation during HBase scan workloads on FIPS-enabled clusters utilizing AES encryption.

Cloudera Runtime 7.3.2.100 CHF 1

There are no behavioral changes in this release.

Cloudera Runtime 7.3.2

Cloudera Runtime 7.3.2 introduces functional adjustments, behavioral updates for HBase, and includes all service packs and cumulative hotfixes from 7.3.1.100 through 7.3.1.700. For a comprehensive record of all functional adjustments in Cloudera Runtime 7.3.1.x, see Behavioral Changes.

Summary: HBOSS related configuration items are removed.

Previous behavior:

HBase contains the following HBOSS related configuration items.

• fs.hboss.fs.s3a.impl
• fs.hboss.sync.impl

New behavior:

The above configuration items are removed because HBOSS support is deprecated.

Summary: Removed the hbase.secure.rpc.engine configuration property

Previous behavior:

The hbase.secure.rpc.engine configuration property is obsolete because HBase performs replication securely by default.

New behavior:

The hbase.secure.rpc.engine configuration property is removed because it is obsolete and no longer needed.

Summary: The default values for the following configuration items are updated

Previous behavior:

Parameter name	Description	Default value
hbase.bucketcache.minfactor	The minimum percentage of BucketCache usage that should be targeted by the mass eviction process.	-
hbase.server.netty.tls.client.auth.mode	The client authentication mode for mTLS authentication when TLS RPC is in use. Three modes are NEED, WANT and NONE.	NEED
ip_version	Specifies the IP version the service must use for network communication. IPv4 - Uses IPv4 exclusively. IPv6 - Uses IPv6 exclusively. Dual-stack (IPv4 &IPv6) - Supports both IPv4 and IPv6, enabling communication over both protocols.	-
hbase.client.netty.tls.enabled	Encrypt communication between clients and HBase RPC client mode using Transport Layer Security (TLS) (formerly known as Secure Socket Layer (SSL)).	-
hbase.bucketcache.acceptfactor	The percentage of BucketCache usage that must trigger the eviction of blocks.	-
hbase.rpc.tls.truststore.location	The location on disk of the trust store, in .jks format, used to confirm the authenticity of TLS/SSL servers that HBase Client RPC might connect to. This trust store must contain the certificate(s) used to sign the service(s) connected to. If this parameter is not provided, the default list of well-known certificate authorities is used instead.	CM_AUTO_TLS
	The implementation to use for S3A FileSystem access.	org.apache.hadoop.hbase.oss.HBaseObjectStoreSemantics
hbase.rpc.tls.truststore.password	The password for the HBase Client RPC TLS/SSL Trust Store File. This password is not required to access the trust store; this field can be left blank. This password provides optional integrity checking of the file. The contents of trust stores are certificates, and certificates are public information.	CM_AUTO_TLS

New behavior:

Parameter name	Description	Default value
hbase.bucketcache.minfactor	The minimum percentage of BucketCache usage that should be targeted by the mass eviction process.	0.95
hbase.server.netty.tls.client.auth.mode	The client authentication mode for mTLS authentication when TLS RPC is in use. Three modes are NEED, WANT and NONE.	NONE
ip_version	Specifies the IP version the service must use for network communication. IPv4 - Uses IPv4 exclusively. IPv6 - Uses IPv6 exclusively. Dual-stack (IPv4 &IPv6) - Supports both IPv4 and IPv6, enabling communication over both protocols.	IPV4
hbase.client.netty.tls.enabled	Encrypt communication between clients and HBase RPC client mode using Transport Layer Security (TLS) (formerly known as Secure Socket Layer (SSL)).	FALSE
hbase.bucketcache.acceptfactor	The percentage of BucketCache usage that must trigger the eviction of blocks.	0.98
hbase.rpc.tls.truststore.location	The location on disk of the trust store, in .jks format, used to confirm the authenticity of TLS/SSL servers that HBase Client RPC might connect to. This trust store must contain the certificate(s) used to sign the service(s) connected to. If this parameter is not provided, the default list of well-known certificate authorities is used instead.	None
	The implementation to use for S3A FileSystem access.	org.apache.hadoop.fs.s3a.S3AFileSystem
hbase.rpc.tls.truststore.password	The password for the HBase Client RPC TLS/SSL Trust Store File. This password is not required to access the trust store; this field can be left blank. This password provides optional integrity checking of the file. The contents of trust stores are certificates, and certificates are public information.	None

Summary: Add security headers to Thrift/HTTP server

Previous behavior:

Previously, security headers were absent in the responses of Thrift or HTTP servers when utilizing HBase-exposed services.

New behavior:

To address this, additional security headers are introduced in the responses of the HBase Thrift server when HTTP or HTTPS transport is enabled.

Apache JIRA: HBASE-27118