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-2 compliance: A U.S. government computer security standard for cryptographic modules.

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-2 compliance

The Federal Information Processing Standard (FIPS) is a U.S. government computer security standard (including FIPS 140-1, FIPS 140-2, and FIPS PUB 140-2) used to validate and certify software cryptographic modules. For a Confluent Platform deployment to be FIPS-compliant, the following components must be FIPS-compliant:

• 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-2 compliance

The following Confluent Platform components are FIPS-compliant:

• 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 (ansible-short|) 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.
• 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 140-2 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 of PKCS12 (BCFKS supported by Bouncy Castle) type. OpenSSL can create an encrypted keystore of PKCS12 type. You can use the Java keytool to convert existing JKS keystore to BCFKS.

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-2 compliance 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-2 compliance through the following mechanisms:

• TLS configuration: The Confluent REST APIs can be configured to use FIPS 140-2 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-2 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: Red Hat Enterprise Linux (RHEL) 8.x or later.
• Enable FIPS mode on RHEL 8.x or later.
• Use the FIPS-certified edition of Bouncy Castle Java (version 1.0.2), 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=

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

To configure Confluent Platform components for FIPS 140-2 compliance:

1. Specify the following parameters in the properties file:

   enable.fips=true
   security.providers=io.confluent.kafka.security.fips.provider.BcFipsProviderCreator,io.confluent.kafka.security.fips.provider.BcFipsJsseProviderCreator
   ssl.enabled.protocols=TLSv1.3
   

2. 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.
• 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.

Important

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

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

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