Security Compliance in Confluent Platform

This document provides a comprehensive guide to security compliance in Confluent Platform, focusing on two key areas:

SSAE 18 SOC 2 certification: An industry-recognized review of Confluent’s security controls environment.
FIPS 140 compliance (FIPS 140-2 and FIPS 140-3): U.S. government standards for validating cryptographic modules used by Confluent Platform components.

Note

The National Institute of Standards and Technology (NIST) validation program is transitioning from FIPS 140-2 to FIPS 140-3, and new validations are expected to use FIPS 140-3. FIPS 140-3 is the recommended mode for all deployments. Aligning with this transition, Confluent Platform 8.2 and later uses FIPS 140-3 as the default FIPS mode. FIPS 140-2 should only be used as a fallback for backward compatibility with existing validated environments.

By following this guide, you can configure your Confluent Platform clusters to adhere to these compliance standards, enhancing the security and trustworthiness of your data infrastructure.

SSAE 18 SOC 2

Confluent contracts annually with qualified external audit teams to provide an industry recognized review of our security controls environment relating to security, availability, and confidentiality. The SSAE 18 SOC 2 report is available upon request.

To request a copy of the latest SSAE 18 SOC 2 report, complete the request form at Trust & Security.

FIPS 140 compliance

The Federal Information Processing Standard (FIPS) is a U.S. government computer security standard (including FIPS 140-1, FIPS 140-2, FIPS 140-3, and FIPS PUB 140-2) used to validate and certify software cryptographic modules.

Confluent Platform supports both FIPS 140-2 and FIPS 140-3:

FIPS 140-2 remains acceptable for existing deployments that are already validated on FIPS 140-2 modules.
FIPS 140-3 is supported starting with Confluent Platform 8.2. This is the default FIPS mode when you enable FIPS in Confluent Platform 8.2 and later, aligning with updated NIST requirements and the FIPS 140-3 transition timeline.

For a Confluent Platform deployment to be FIPS-compliant (either 140-2 or 140-3), the following requirements apply:

All network communications must be encrypted and use FIPS-compliant ciphers.
Use FIPS-validated modules for all cryptographic operations, including generating certificates, hashing, encryption, integrity checks (validating signatures), and authentication.

Components supporting FIPS 140 compliance

The following Confluent Platform components support FIPS 140-2 and FIPS 140-3 compliance when configured to run in FIPS mode:

Confluent Server brokers
Schema Registry
ksqlDB
Kafka Connect
KRaft controllers
Metadata Service (MDS) - PEM certificates must conform to the PKCS#8 standard, which allows for FIPS-compliant deployments using Connect, ksqlDB, and Schema Registry

Confluent for Kubernetes (CFK) and Ansible Playbooks for Confluent Platform (Confluent Ansible) can deploy these components in FIPS-compliant mode. For details, see Security Compliance in Confluent for Kubernetes.

To be FIPS compliant, every Confluent Platform component must be configured to use FIPS-compliant ciphers and encryption algorithms using the following properties:

enable.fips: Set to true to enable FIPS-compliant mode and enforce FIPS-compliance using FIPS validators.
enable.fips.mode: Specifies the FIPS compliance mode. Valid values are fips-140-2 and fips-140-3. FIPS 140-3 is the recommended mode (default in Confluent Platform 8.2 and later). Use FIPS 140-2 only as a fallback for backward compatibility with existing validated environments.
security.providers: Specify the list of security providers to use for FIPS-compliant cipher enforcement, separated by ,. This property is defined by KIP-492. Each provider creator class must implement the SecurityProviderCreator interface. The Bouncy Castle FIPS JSSE Security Provider is the only supported provider for FIPS-compliant cipher enforcement.

The following sections provide information on how to configure Confluent Platform components for FIPS compliance.

Cryptographic data

To be FIPS-compliant, all cryptographic data at rest and data in motion must be encrypted using FIPS-compliant ciphers. Cryptographic materials, such as keys and the keystore, must be password-encrypted and use the BCFKS (Bouncy Castle FIPS KeyStore) format. BCFKS is the only FIPS-compliant keystore type supported by the Bouncy Castle FIPS provider. You can use the Java keytool to convert existing JKS or PKCS12 keystores to BCFKS format.

TLS encryption

Confluent Platform supports TLS encryption for all client-to-broker and broker-to-broker. The following configuration parameters are required for Confluent Platform components to support FIPS 140 compliance (FIPS 140-2 and FIPS 140-3) using the BCFKS type keystore and other TLS properties.

Any cipher suites for TLS connections from ksqlDB, Connect, Confluent Control Center , or Schema Registry to a broker are enforced by the broker.

# TLS configuration
ssl.enabled.protocols=TLSv1.2,TLSv1.3
ssl.keymanager.algorithm=PKIX
ssl.trustmanager.algorithm=PKIX
ssl.keystore.type=BCFKS
ssl.truststore.type=BCFKS
ssl.truststore.location=<path-to-ssl-truststore>
ssl.truststore.password=<ssl-truststore-password>
ssl.keystore.location=<path-to-ssl-keystore>
ssl.keystore.password=<ssl-keystore-password>
ssl.key.password=<ssl-key-password>

Clients

Java clients require FIPS-compliant JSSE and JCA providers are installed.
Non-Java clients require the appropriate FIPS-certified JAR files. For example, the Go client requires the BoringCrypto library. For native clients that depend on OpenSSL, ensure that FIPS-certified version (3.0 or later) is installed.

Confluent REST APIs

The Confluent REST APIs support FIPS 140 compliance (FIPS 140-2 and FIPS 140-3) through the following mechanisms:

TLS configuration: The Confluent REST APIs can be configured to use FIPS 140 compliant cipher suites and protocols (TLSv1.2 and TLSv1.3) when communicating with clients. This ensures that the data transmitted over the network is encrypted using approved cryptographic algorithms.
Integration with FIPS-compliant components: The Confluent REST APIs can be integrated with FIPS-compliant components, such as the Bouncy Castle FIPS JSSE Security Provider, to ensure that the data is encrypted using FIPS-compliant algorithms.
Configuration automation: You can use tools like Confluent for Kubernetes (CFK) and Confluent Ansible to automate the configuration of the platform for FIPS 140 compliance. This includes configuring the Confluent REST APIs to use FIPS-compliant settings.
For details, see:
- Deploy and Manage Confluent Platform Using Confluent for Kubernetes
- Ansible Playbooks for Confluent Platform FIPS

Confluent CLI

The Confluent CLI for Manage Secrets in Confluent Platform protection implements encryption and key generation using a cryptographic library that is not FIPS-compliant. However, the decryption function is implemented in Java on the broker side, so the decryption algorithm is FIPS-compliant as long as the broker is configured in FIPS operational readiness mode.

Prerequisites

Operating system:
- For FIPS 140-3 compliance (recommended): Red Hat Enterprise Linux (RHEL) 9.x or later.
- For FIPS 140-2 compatibility mode: Red Hat Enterprise Linux (RHEL) 8.x or later.
Note
Only RHEL 9.x and later is certified to be fully FIPS 140-3 compliant. RHEL 8.x provides a mix of FIPS 140-2 and FIPS 140-3 compliance.
Enable FIPS mode on your RHEL system. See the following guides:
- FIPS mode on RHEL 9
- FIPS mode on RHEL 8
Use the FIPS-certified edition of Bouncy Castle Java (version 2.0.0 and later), which provides cryptographic cipher suites for TLS communication and encryption/decryption service (provided as part of the distribution).
Install and run the rng-tools package, which can help you test for and avoid entropy in your system.
Run FIPs-compliant cryptographic libraries and TLS encryption for data in motion (or data in transit), which means you must configure Confluent Platform with TLS communications for all publish/subscribe client-to-broker and component-to-broker communications.
- The default keystore format is JKS, which is not a standardized format, is deprecated, and not supported by FIPS providers.
- The BC FIPS provider supports two types of keystore formats: PKCS12 and BCFKS. Only the BCFKS keystore is FIPS-compliant. Follow the steps below to create a BCFKS keystore or convert a PKCS12 keystore to BCFKS format.

Configure Confluent Platform clusters for FIPS compliance

Configure TLS

The following configuration example is not specific to FIPS or a new configuration; rather, it shows the specific use case to configure TLS so that it includes the BCFKS keystore for TLS communication. You must also include listeners prefixed with listener.name. for each listener in the TLS configuration. The listener configuration in the example below is based on the following definition:

listener.security.protocol.map = INTERNAL:SASL_SSL,BROKER:SSL,EXTERNAL:SSL \
   listeners = INTERNAL://:9092,BROKER://:9091,EXTERNAL://:9093

# TLS configuration
ssl.keymanager.algorithm=PKIX
ssl.trustmanager.algorithm=PKIX
ssl.keystore.type=BCFKS
ssl.truststore.type=BCFKS
ssl.truststore.location=<path-to-ssl-truststore>
ssl.truststore.password=<ssl-truststore-password>
ssl.keystore.location=<path-to-ssl-keystore>
ssl.keystore.password=<ssl-keystore-password>
ssl.key.password= <ssl-key-password>

# External listener configuration
listener.name.external.ssl.keymanager.algorithm=PKIX
listener.name.external.ssl.trustmanager.algorithm=PKIX
listener.name.external.ssl.keystore.type=BCFKS
listener.name.external.ssl.truststore.type=BCFKS
listener.name.external.ssl.truststore.location=<path-to-ssl-truststore>
listener.name.external.ssl.truststore.password=<ssl-truststore-password>
listener.name.external.ssl.keystore.location=<path-to-ssl-keystore>
listener.name.external.ssl.keystore.password=<ssl-keystore-password>
listener.name.external.ssl.key.password= <ssl-key-password>

Configure MDS

MDS provides additional FIPS-compliant cipher enforcement over HTTPS communication to and from MDS. The following example shows an MDS configuration for FIPS-compliance:

confluent.metadata.server.ssl.keystore.type=BCFKS
confluent.metadata.server.ssl.keymanager.algorithm=PKIX
confluent.metadata.server.ssl.keystore.location=kafka.server.keystore.bcfks
confluent.metadata.server.ssl.keystore.password=
confluent.metadata.server.ssl.key.password=

To enable FIPS mode and select the FIPS standard for MDS, configure the following MDS-specific FIPS properties in addition to the SSL settings above:

# Enable FIPS in MDS and select the FIPS mode
confluent.metadata.server.enable.fips=true
confluent.metadata.server.enable.fips.mode=fips-140-3

# TLS protocols and cipher suites for FIPS 140-3
confluent.metadata.server.ssl.enabled.protocols=TLSv1.3,TLSv1.2
confluent.metadata.server.ssl.cipher.suites=TLS_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

# When OAuth is enabled, ensure endpoint identification is configured
confluent.metadata.server.confluent.idp.ssl.endpoint.identification.algorithm=https

You can also set confluent.metadata.server.enable.fips.mode=fips-140-2 for FIPS 140-2 compatibility in environments that are already validated on FIPS 140-2 modules.

Configure keystores

Convert a PKCS12 keystore to BCFKS format

If you are using a PKCS12 keystore, convert it to BCFKS keystore by running the following keytool command:

keytool -importkeystore -v -srckeystore kafka.server.keystore.pk12 \
  -srcstoretype PKCS12 \
  -providername BCFIPS \
  -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \
  -providerpath /Users/fips-user/tmp/ssl/bcfks/bc-fips-1.0.2.jar \
  -destkeystore kafka.server.keystore.bcfks \
  -deststoretype BCFKS

Configure keys and certificates using BCFKS

Creating TLS/SSL Keys and Certificates provides the steps to configure a keystore and generate a certificate. When using BCFKS, the steps are the same, but the configuration is different because you must add the storetype, providerpath, and providerclass. Your configuration should resemble the following example:

keytool -keystore kafka.server.keystore.bcfks \
  -alias localhost \
  -validity 720 \
  -genkeypair \
  -keyalg RSA \
  -keysize 2048 \
  -storepass testfips \
  -keypass testfips \
  -storetype BCFKS \
  -providerpath /Users/fips-user/tmp/ssl/bcfks/bc-fips-1.0.2.jar \
  -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \
  -dname CN=localhost \
  -ext SAN=DNS:localhost \
openssl req -new -x509 \
  -keyout ca-key \
  -out ca-cert \
  -days 720
keytool -keystore kafka.client.truststore.bcfks
  -storetype BCFKS \
  -alias CARoot \
  -import \
  -file ca-cert \
  -providerpath /Users/fips-user/tmp/ssl/bcfks/bc-fips-1.0.2.jar \
  -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
keytool -keystore kafka.server.truststore.bcfks \
  -storetype BCFKS \
  -alias CARoot \
  -importcert \
  -file ca-cert \
  -providerpath /Users/fips-user/tmp/ssl/bcfks/bc-fips-1.0.2.jar \
  -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
keytool -keystore kafka.server.keystore.bcfks
  -alias localhost \
  -storepass testfips \
  -keypass testfips
  -storetype BCFKS \
  -certreq \
  -file cert-file \
  -providerpath /Users/fips-user/tmp/ssl/bcfks/bc-fips-1.0.2.jar \
  -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
openssl x509 -req -CA ca-cert \
  -CAkey ca-key \
  -in cert-file \
  -out cert-signed \
  -days 720 \
  -CAcreateserial \-passin pass:testfips
keytool -keystore kafka.server.keystore.bcfks
  -storetype BCFKS \
  -alias CARoot \
  -import \
  -file ca-cert \
  -storepass testfips \
  -providerpath /Users/fips-user/tmp/ssl/bcfks/bc-fips-1.0.2.jar \
  -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
cat ca-cert cert-signed > cert
keytool -keystore kafka.server.keystore.bcfks \
  -storetype BCFKS \
  -storepass testfips \
  -alias localhost
  -import \
  -file cert \
  -providerpath /Users/fips-user/tmp/ssl/bcfks/bc-fips-1.0.2.jar \
  -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider

Configure Confluent Platform components

Use the following configuration properties to enable FIPS mode and select the FIPS standard (140-2 or 140-3) enforced by Confluent Platform components.

Property	Type	Default	Description
`enable.fips`	Boolean	`false`	Enables FIPS validation for this component. When set to `true`, the component validates TLS protocols and cipher suites using the FIPS validator before starting.
`enable.fips.mode`	String	`fips-140-3`	Specifies the FIPS compliance mode. Valid values are `fips-140-2` and `fips-140-3`. FIPS 140-3 is the recommended mode for all deployments. Use FIPS 140-2 only as a fallback for backward compatibility with existing validated environments. This property is available in Confluent Platform 8.2 and later.
`security.providers`	String	(none)	Comma-separated list of security provider creator classes to install FIPS-compliant cryptographic providers into the JVM. For Confluent Platform, use the Bouncy Castle FIPS provider creators shown in the examples below.

FIPS 140-3 (default for CP 8.2 and later)

# Enable FIPS mode and use FIPS 140-3 (default)
enable.fips=true
enable.fips.mode=fips-140-3

# Install Bouncy Castle FIPS providers
security.providers=io.confluent.kafka.security.fips.provider.BcFipsProviderCreator,io.confluent.kafka.security.fips.provider.BcFipsJsseProviderCreator

# TLS protocols and cipher suites
ssl.enabled.protocols=TLSv1.3,TLSv1.2
ssl.cipher.suites=TLS_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

FIPS 140-2 compatibility mode

# Enable FIPS mode using FIPS 140-2 compatibility
enable.fips=true
enable.fips.mode=fips-140-2

security.providers=io.confluent.kafka.security.fips.provider.BcFipsProviderCreator,io.confluent.kafka.security.fips.provider.BcFipsJsseProviderCreator

ssl.enabled.protocols=TLSv1.3,TLSv1.2
ssl.cipher.suites=TLS_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

To configure Confluent Platform components for FIPS 140 compliance:

Set the FIPS properties (enable.fips, enable.fips.mode, and security.providers) as shown in the examples above.
Enable TLS encryption for data in motion.

Note

Confluent Platform uses TLS 1.3 by default. Both TLS 1.3 and TLS 1.2 are supported for FIPS 140-2 and FIPS 140-3.
Bouncy Castle is the only supported FIPS provider. It enables a second level of cipher enforcement at the broker level, beyond settings defined in ssl.cipher.suites.
If cipher suites are not configured, Bouncy Castle provider determines the values.
For a complete list of supported cipher suites, see: Appendix B – Supported Cipher Suites.

Confluent Platform will not start if the specified TLS version and cipher suites are not FIPS-compliant.

When you enable FIPS mode, Confluent Platform validates the following configuration to ensure FIPS-compliant operation:

LDAP connections must use ldaps://.
TLS cipher suites must be FIPS-compliant.
TLS protocols must be limited to TLSv1.2 and/or TLSv1.3.
OAuth identity provider endpoints must use https://.
Confluent Platform REST endpoints and components must be configured to use https:// (no plain HTTP).
Kafka listener security protocols must be configured as SASL_SSL or SSL.

These configurations ensure that Confluent Platform uses FIPS-compliant cryptographic modules and protocols, which is essential for meeting FIPS 140 compliance requirements (FIPS 140-2 and FIPS 140-3).

Enable FIPS mode

When running Confluent Platform in FIPS-enabled mode, the cryptographic use of the following technologies only runs using FIPS-compliant ciphers:

Brokers, consumers, and producers using FIPS JSSE provider
JVM using FIPS JSSE provider

Any cipher suites for TLS connections from ksqlDB, Connect, Confluent Control Center , or Schema Registry to a broker are enforced by the broker.

Verify RHEL is operating in FIPS mode

Optionally, you can verify that RHEL is operating in FIPS mode by running the following commands:

cat /proc/sys/crypto/fips_enabled
sysctl crypto.fips_enabled

This is an example of the expected output:

cat /proc/sys/crypto/fips_enabled
1
sysctl crypto.fips_enabled
crypto.fips_enabled = 1

Note

Ensuring RHEL is in FIPS mode is a system-level configuration and may be required for full FIPS compliance in your environment.

Clients and tools

Export the public certificate from the keystore

To export the public certificate and use it for HTTP clients (such as curl), run the following keytool command:

keytool -exportcert -rfc -file kafka.server.keystore.cer \
  -alias localhost \
  -keystore kafka.server.keystore.bcfks \
  -storetype bcfks \
  -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \
  -providerpath /path/to/bc-fips-1.0.2.jar \
  -storepass your_keystore_password