FIPS deployments: Constraints and operational guardrails
Review unsupported configurations, active known issues, and shared infrastructure responsibilities for FIPS cluster deployments. These environments integrate platform components with SafeLogic cryptographic modules to establish secure operational guardrails while delegating RHEL operating system maintenance.
Unsupported FIPS deployments
The following
deployment scenarios and component features are not supported in FIPS-compliant
environments:
- Changing the FIPS status of an existing cluster post-installation.
- Using the MapReduceIndexerTool (MRIT)
localfscomponent when Secure Hash Algorithm 2 (SHA-2) compatibility is required.
Known issues in FIPS
- OpenSSL HMAC symlink for RHEL8.x FIPS
- Cloudera Manager 7.13.2 and lower versions
Responsibilities and guardrails
FIPS operational boundaries define how Cloudera platform components integrate with SafeLogic cryptographic modules while leaving base operating system and database configuration to the customer.
While Cloudera integrates its platform components to work seamlessly with FIPS-validated cryptography, system
operators must manage the following underlying
platform compliance boundaries:
- Cryptographic layer integrity – Cloudera platform components are configured to leverage FIPS-validated libraries appropriately, but the underlying verification certificates are held directly by the third-party module vendors (SafeLogic and Red Hat).
- OS and database maintenance – Enabling FIPS mode on RHEL or configuring external metadata databases to communicate using FIPS-compliant TLS parameters is the sole responsibility of the customer.
