FIPS mode in Cloudera Streams Messaging - Kubernetes Operator

You can deploy Cloudera Streams Messaging - Kubernetes Operator components in FIPS 140-2/3 compliant mode to meet strict security requirements. Strimzi and its managed components automatically enable FIPS mode on FIPS-enabled RHEL 8.x or higher hosts. Cloudera Surveyor for Apache Kafka is FIPS compliant, but requires you to manually enable FIPS mode through configuration. Cloudera Surveyor also supports the use of custom security providers.

Host prerequisites

Cloudera Streams Messaging - Kubernetes Operator requires host prerequisites to run in FIPS mode.

The following host prerequisites are valid for Cloudera Streams Messaging - Kubernetes Operator:

Host operating system must be Red Hat Enterprise Linux (RHEL) 8.x or a higher version.
FIPS mode must be enabled on the host.

If the host is FIPS-enabled, Containers running on that host will be FIPS-enabled too. All container images shipped with Cloudera Streams Messaging - Kubernetes Operator are built using RHEL9-based Universal Base Images (UBI) that are FIPS-compliant. This means that running Containers will be RHEL-based and FIPS-compliant.

Strimzi

Strimzi as well as components managed by Strimzi are FIPS 140-2/3 compliant by default and run in FIPS mode automatically in FIPS-enabled environments.

When deployed on a FIPS-enabled cluster, the OpenJDK in the Containers of Strimzi automatically activates its FIPS mode. This requires no explicit configuration for Strimzi, it automatically uses the FIPS-compliant cryptographic libraries built into its Java runtime. Inserting additional security providers is not required.

Strimzi is also responsible for managing Kafka and Cruise Control. When deployed in FIPS mode, Strimzi generates keystores, truststores, and configuration files for these components in a FIPS-compatible way. Running Kafka or Cruise Control in FIPS mode does not require any explicit configuration, and additional security providers are not required.

Cloudera Surveyor

Cloudera Surveyor supports running in a FIPS 140-2/3 compliant manner. However, FIPS mode is disabled by default and must be explicitly enabled.

Enabling FIPS mode enforces strict security controls and changes the configuration of Cloudera Surveyor in the following ways:

The Java runtime is configured to use a FIPS‑capable cryptographic provider first so that cryptographic operations use FIPS‑approved implementations.
All TLS truststores must be in the BCFKS (Bouncy Castle FIPS Keystore) format and must be password-protected.
The security settings of the Java Virtual Machine are adjusted so the runtime uses FIPS‑approved algorithms and a cryptographically strong source of randomness.

If required, you can also configure the use of additional, custom security providers. These must be mounted to the Cloudera Surveyor Container.

Enabling FIPS mode for Cloudera Surveyor

Enable FIPS mode for Cloudera Surveyor by setting the fipsMode property to true in your values file.

#...
fipsMode: true

Configuring additional FIPS security providers in Cloudera Surveyor

Cloudera Surveyor integrates and uses a FIPS-compliant security provider when FIPS mode is enabled. If required, you can mount additional custom security providers and configure Cloudera Surveyor to use them.

A volume that contains necessary provider JARs must be available. The volume should support RWX.
The following steps use CryptoComply for Java (CCJ) SafeLogic - Java JCE Provider as an example.

Mount the provider JAR file to the Cloudera Surveyor Container.
Use the extraVolumes and extraVolumeMounts properties in your values file.
```
#...
extraVolumes:
  - name: [***EXTRA VOLUME NAME***]
    persistentVolumeClaim:
      claimName: [***RWX VOLUME CLAIM***]

extraVolumeMounts:
  - name: [***EXTRA VOLUME NAME***]
    mountPath: /opt/providers
    readOnly: false
```
- extraVolumes – List of additional volumes to attach to the Pod. This allows you to mount various types of volumes, such as secret, configMap, or persistentVolumeClaim.
- extraVolumes[*].name – The name of the volume. Must match the corresponding name in the extraVolumeMounts property.
- extraVolumes[*].persistentVolumeClaim – The volume configuration. Can be any valid Kubernetes volume type, such as secret, configMap, or persistentVolumeClaim.
- extraVolumeMounts – List of volume mounts that specify how volumes are mounted into the Container.
- extraVolumeMount[*].name – The name of the volume to mount. Must match a volume defined in the extraVolumes property.
- extraVolumeMount[*].mountPath – The path within the Container where the volume is mounted.
- extraVolumeMount[*].readOnly – Whether the volume is mounted read-only. The default value is false.
Configure Cloudera Surveyor to use the provider.
Use the securityProviders property in your values file. This appends your custom provider class to the list of security providers.
```
#...
securityProviders:
  - providerClassName: "com.safelogic.cryptocomply.jcajce.provider.CryptoComplyFipsProvider"
    argument: "[***PROVIDER ARGUMENT***]"
    classpath:
      - "/opt/providers/ccj-3.0.2.1.jar"
```
- securityProviders – List of security providers to load.
- securityProviders[*].providerClassName – Class name of the provider.
- securityProviders[*].argument – Argument to pass to provider.
- securityProviders[*].classpath – List of filesystem paths to add to the classpath for this provider to function. This is an absolute file path in the /my-dir/my-file form, in which my-dir is the mountPath from the extraVolumeMounts property and my-file is the provider file name in that directory.

Limitations

FIPS mode in Cloudera Streams Messaging - Kubernetes Operator has limitations for Strimzi and Kafka.

Strimzi

JMX monitoring has the following limitations in FIPS mode that make it unsuitable for secure monitoring:

JMX authentication – Password-based authentication for JMX is not supported in FIPS mode. This forces you to expose JMX without authentication, creating significant security risks.
JMX Trans compatibility – The JMX Trans tool is outdated and does not support Java 17. The Strimzi container image for JMX Trans uses Java 11, which lacks the improved FIPS support found in modern OpenJDK versions, creating compatibility and security issues.

For these reasons, Cloudera recommends using Prometheus metrics instead of JMX for monitoring Strimzi in FIPS environments.

Kafka

The following FIPS mode limitations are valid for Kafka:

For systems employing Simple Authentication and Security Layer (SASL), Cloudera recommends explicitly select a strong mechanism such as SCRAM-SHA-512 to ensure FIPS compatibility by default.
In environments where required security algorithms are unavailable, some SASL mechanisms, such as PLAIN, as selected authentication might fail. Although client-side configurations can sometimes serve as a workaround, Cloudera does not recommend client-side configuration workarounds. Client-side modifications might introduce non-compliant cryptographic modules or policies, which could compromise the FIPS compatibility of the entire cluster. Always use a fully FIPS-compliant mechanism instead.