FIPS 140 compliance

Federal Information Processing Standards (FIPS) 140-2 and 140-3 define security requirements for cryptographic modules. These standards were developed by the National Institute of Standards and Technology (NIST) for use by United States federal government agencies and contractors. You can configure Cloudera Base on premises to use FIPS-approved cryptography.

Cloudera Flow Management supports the following FIPS configurations:

Cloudera Flow Management 2.1.5 and later 2.x versions support FIPS 140-2.
Cloudera Flow Management 4.12.0.x supports FIPS 140-2.
Cloudera Flow Management 4.12.0.10001 (Service Pack 1) supports:
- FIPS 140-2 when installed on Red Hat Enterprise Linux 8.8 or 8.10.
- FIPS 140-3 when installed on Red Hat Enterprise Linux 9.6.

To install and configure a FIPS-compliant Cloudera cluster, see the FIPS compliance and integration guide. When FIPS and Auto-TLS are configured, Cloudera components use the BouncyCastle FIPS Keystore (BCFKS) format.

Consider the following points when using Cloudera Flow Management in a FIPS-enabled environment:

Cloudera Flow Management can run on a FIPS-enabled operating system and use FIPS-approved cryptographic libraries.
FIPS 140-3 compliance is enforced at the operating-system and environment level.
For FIPS 140-3 deployments, Cloudera Flow Management 4.12.0.10000 (Service Pack 1) uses updated cryptographic modules and Java security settings. It also removes the Cloudera OpenSSL JNI dependency and includes the Cloudera SASL provider for Kerberos.
By default, NiFi keystores and truststores use Java KeyStore (JKS) format, which is not FIPS compliant.
FIPS 140-3 requires passwords in the whole system that are at least 14 characters long (>=112 bits). A login attempt using a shorter password is rejected immediately and gets recorded as a failed login attempt, even if the password was correctly entered.
NiFi dataflows are not FIPS compliant by default. You must design and configure each dataflow to be FIPS compliant.
For FIPS 140-3 deployments, you can protect NiFi sensitive properties, such as database connection pool passwords, by using a secret key generated with the approved PBKDF2 algorithm. For instructions, see Encrypting NiFi sensitive properties with FIPS 140-3 approved algorithm.

For the complete standards, see

FIPS 140-2 Security Requirements for Cryptographic Modules
FIPS 140-3 Security Requirements for Cryptographic Modules

Upgrading FIPS-enabled deployments

Upgrading a Cloudera Flow Management 4.12.0 FIPS 140-2 deployment to Cloudera Flow Management 4.12.0.10000 (Service Pack 1) does not change it to FIPS 140-3. The upgraded deployment remains FIPS 140-2 compliant and continues to use Red Hat Enterprise Linux 8.8 or 8.10.

An in-place upgrade from FIPS 140-2 to FIPS 140-3 is not supported. FIPS 140-3 requires Red Hat Enterprise Linux 9.6, while the previous FIPS 140-2 configurations are supported only on Red Hat Enterprise Linux 8.8 and 8.10. To move from FIPS 140-2 to FIPS 140-3, you must install a new Cloudera Flow Management 4.12.0.10000 (Service Pack 1) deployment on Red Hat Enterprise Linux 9.6 and migrate your data to the new deployment.

You can upgrade to Cloudera Flow Management 4.12.0.10000 (Service Pack 1) without creating a new deployment if you intend to continue using FIPS 140-2 or if your deployment does not use FIPS.

Required security providers and JAR files

Cloudera Flow Management requires the following security providers and JAR files in a FIPS-enabled environment.

Bouncy Castle TLS

The Bouncy Castle TLS library (bctls-[***version***].jar) provides the BouncyCastleJsseProvider. When this provider is configured in java.security, its TLS implementation takes precedence over the standard Java implementation.

The Bouncy Castle TLS JAR file depends on bcutil-[***version***].jar.

By default, Bouncy Castle TLS does not enable GCM-based cipher suites. As a result, TLS server components might attempt to negotiate weak AES-CBC cipher suites that modern browsers such as Google Chrome and Mozilla Firefox, do not accept. This can cause cipher mismatch errors when connecting to a FIPS-enabled Cloudera Flow Management deployment.

To enable GCM-based cipher suites, add the following Java System property to the bootstrap.conf file: java.arg.allowgcm=-Dorg.bouncycastle.jsse.fips.allowGCMCiphers=true

Enabling GCM-based ciphers allows clients to negotiate modern TLS cipher suites and helps prevent connection failures caused by incompatible cipher suites.

SafeLogic CryptoComply for Java

The SafeLogic CryptoComply for Java JAR file (ccj-4.0.0.jar) provides the CryptoComplyFipsProvider, which supplies FIPS-validated cryptographic operations.

Configure the following property in java.security to restrict the provider to FIPS-approved algorithms and cipher suites (such as AES-GCM for TLS): com.safelogic.cryptocomply.fips.approved_only=true in java.security.

Cloudera SASL provider

For FIPS 140-3, the ClouderaSaslProvider, supplied in sasl-sha256aes-<version>.jar, replaces non-FIPS-compliant algorithms used by standard Hadoop and Java Simple Authentication and Security Layer (SASL) mechanisms. It uses SHA-256 for message integrity and token verification and AES for payload encryption.

To enable NiFi to communicate with Hadoop components, configure the following environment variable using a Cloudera Manager safety valve: HADOOP_SASL_MECHANISM=DIGEST-SHA

Configuring the JDK for Cloudera Flow Management

These security components are also required when enabling FIPS for Cloudera Base on premises. However, Cloudera Base on premises uses JDK 17, while Cloudera Flow Management 4.x requires JDK 21.

After configuring FIPS for the JDK 17 installation, repeat the applicable security-provider configuration for the JDK 21 installation used by Cloudera Flow Management.

For information about obtaining and configuring the required libraries, see Preparing the hosts in the FIPS integration for JDK 17 documentation.

For information about installing JDK 21 for Cloudera Flow Management, see Installing and configuring JDK.