<a id="security-compliance"></a>

# 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.

<a id="soc-2-report"></a>

## 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](https://www.confluent.io/trust-and-security/).

<a id="fips-operational-readiness"></a>

## FIPS 140 compliance

The [Federal Information Processing Standard (FIPS)](https://www.nist.gov/itl/current-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](https://docs.confluent.io/operator/current/co-security-compliance.html).

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, and is the
  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](https://cwiki.apache.org/confluence/display/KAFKA/KIP-492%3A+Add+java+security+providers+in+Kafka+Security+config).
  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.

```properties
# 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](../../api-javadoc/index.md#cp-confluent-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](https://docs.confluent.io/operator/current/overview.html)
  * [Ansible Playbooks for Confluent Platform FIPS](https://docs.confluent.io/ansible/current/ansible-encrypt.html#configure-for-fips)

#### Confluent CLI

The Confluent CLI for [Manage Secrets in Confluent Platform](secrets/overview.md#secrets) 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](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9).
  * For FIPS 140-2 compatibility mode: [Red Hat Enterprise Linux (RHEL) 8.x or later](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8).

  #### 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](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening)
  * [FIPS mode on RHEL 8](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening)
* Use the FIPS-certified edition of [Bouncy Castle Java (version 2.0.0 and later)](https://www.bouncycastle.org/download/bouncy-castle-java-fips/),
  which provides cryptographic cipher suites for TLS communication and encryption/decryption
  service (provided as part of the distribution).
* Install and run the [rng-tools](https://developers.redhat.com/blog/2017/10/05/entropy-rhel-based-cloud-instances#)
  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](#create-keystore-using-bcfks) or
    [convert a PKCS12 keystore to BCFKS format](#convert-pkcs12-to-bcfks).

## 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:

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

```properties
# 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:

```properties
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:

```properties
# 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

<a id="convert-pkcs12-to-bcfks"></a>

#### 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:

```shell
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
```

<a id="create-keystore-using-bcfks"></a>

#### Configure keys and certificates using BCFKS

[Creating TLS/SSL Keys and Certificates](../security_tutorial.md#generating-keys-certs) 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:

```shell
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
```

<a id="configure-cp-for-fips"></a>

### 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`.<br/>FIPS 140-3 is the recommended mode for all deployments. Use FIPS 140-2 only as a fallback<br/>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)

```properties
# 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

```properties
# 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:

1. Set the FIPS properties (`enable.fips`, `enable.fips.mode`, and `security.providers`) as shown in the examples above.
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 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](https://downloads.bouncycastle.org/fips-java/docs/BC-FJA-(D)TLSUserGuide-2.0.20.pdf).

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:

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

This is an example of the expected output:

```shell
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

<a id="export-cert-from-keystore"></a>

### 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:

```shell
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
```