Security Compliance

Deploy Federal Information Processing Standard (FIPS) 140-2 or FIPS 140-3 compliant Confluent Platform components with Confluent for Kubernetes (CFK).

FIPS 140-2 and FIPS 140-3

The Federal Information Processing Standard (FIPS) 140 series defines the security requirements for cryptography used in the US federal government systems, including FIPS 140-2 and FIPS 140-3.

While Confluent Platform is not FIPS-certified, it provides FIPS-compliant cipher enforcement at the component level. For background on FIPS in Confluent Platform, see Security compliance for Confluent Platform.

Starting in CFK 3.2.0, CFK can deploy and manage clusters in FIPS-compliant mode. This requires the underlying operating system, cryptographic providers, and Confluent Platform components to already be configured for FIPS 140-2 or FIPS 140-3, as described in Security compliance for Confluent Platform.

The following components can be configured to use FIPS-compliant ciphers on their TLS connections:

Confluent Server
KRaft
Schema Registry
Connect
ksqlDB

Bouncy Castle is the FIPS-compliant Java keystore type required for FIPS-enabled TLS connections. All TLS-enabled components must use this keystore type. These TLS configurations also include those for the listeners, the Metadata Service (MDS), Apache Kafka® REST class, and schema validation.

Bouncy Castle type keystores cannot be used to configure ZooKeeper TLS.

You can use regular keystores to connect non-FIPS-compliant components to the FIPS-enabled listeners.

Deploy CFK in FIPS mode

(Optional) To enable the validating webhooks for CFK in the FIPS mode, you need to provide TLS keys and certificates in Java keystore format. In FIPS mode, the webhook server requires truststore.jks, keystore.jks, and jksPassword.txt.
Install CFK in the FIPS mode.
- From the Confluent Helm repository, using the Helm argument, --set fipsmode=true:
```
helm upgrade --install confluent-operator \
  confluentinc/confluent-for-kubernetes \
  --set fipsmode=true \
  --namespace <namespace>
```
  For details of using a Helm argument, see Deploy CFK with Custom Values.
- Set the following property in the configuration values file.
```
fipsmode: true
```
  For details about using the configuration file, see Deploy CFK with Custom Values.

Note

Upgrading a FIPS-enabled cluster from the ZooKeeper mode to KRaft mode is not currently supported.

As a workaround, turn off the FIPS mode for CFK, migrate to the |kraft| mode, and turn on the FIPS mode for CFK.

Deploy Confluent Platform in FIPS mode

To enable FIPS for Confluent Platform:

Create a secret with the FIPS-compliant keystores and truststores.
Reference the preceding secret in the component custom resources (CRs).

Create FIPS-compliant keystores

To enable FIPS in Confluent Platform, the following keys and files are required:

Bouncy Castle keystore (keystore.bcfks) and truststore (truststore.bcfks)
JKS keystore (keystore.jks) and truststore (truststore.jks) if a TLS connection exists between Kafka and ZooKeeper
JKS password (jksPassword.txt)

The steps in this section use the commands with example use cases. Replace the file locations and other parameters in the examples with those for your environment.

To create Bouncy Castle type keystores, download the Bouncy Castle JAR:

curl https://repo1.maven.org/maven2/org/bouncycastle/bc-fips/1.0.2.3/bc-fips-1.0.2.3.jar \
  -o /tmp/bc-fips-1.0.2.3.jar

Create all the keystores required for deployment.

Create the certificate chain as described in Provide TLS keys and certificates in PEM format:
```
cat ca.pem server.pem > server-chain.pem
```

Create the Bouncy Castle truststore using the JAR you downloaded in Step #1:

keytool -noprompt -keystore truststore.bcfks \
    -storetype BCFKS \
    -alias CARoot \
    -import -file ca.pem \
    -storepass password \
    -keypass password \
    -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \
    -providerpath /tmp/bc-fips-1.0.2.3.jar

Add the server certificate and the key into a PKCS12 file:

openssl pkcs12 -export \
    -in server-chain.pem \
    -inkey server-key.pem \
    -out server.p12 \
    -name localhost \
    -passout pass:mykeypassword

Create the Bouncy Castle keystore out of the PKCS12 created in the previous step:

keytool -importkeystore \
    -srckeystore keystores/server.p12 \
    -srcstoretype pkcs12 \
    -srcstorepass mykeypassword \
    -destkeystore keystore.bcfks \
    -deststorepass password \
    -destkeypass password \
    -deststoretype BCFKS \
    -providername BCFIPS \
    -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \
    -providerpath /tmp/bc-fips-1.0.2.3.jar

Import the certificate authority (CA) into the keystore:

keytool -noprompt -keystore keystore.bcfks \
    -storetype BCFKS \
    -alias CARoot \
    -import -file ca.pem \
    -storepass password \
    -keypass password \
    -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \
    -providerpath /tmp/bc-fips-1.0.2.3.jar

Inspect the keystore contents:

keytool -list -keystore keystore.bcfks \
    -storepass password -v \
    -keypass password \
    -storetype BCFKS \
    -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \
    -providerpath /tmp/bc-fips-1.0.2.3.jar

Because the TLS connection between Kafka and ZooKeeper cannot use Bouncy Castle keystores, you must also create a PKCS12 keystore for those connections.

Create the truststore:

keytool -noprompt -keystore truststore.jks \
    -storetype pkcs12 \
    -alias CARoot \
    -import -file ca.pem \
    -storepass password \
    -keypass password

Create the keystore out of the PKCS12 created in the previous step:

keytool -importkeystore \
    -srckeystore server.p12 \
    -srcstoretype pkcs12 \
    -srcstorepass mykeypassword \
    -deststoretype pkcs12 \
    -destkeystore keystore.jks \
    -deststorepass password \
    -destkeypass password

Import the certificate authority (CA) into the keystore:

keytool -noprompt -keystore keystore.jks \
    -alias CARoot \
    -storetype pkcs12 \
    -import -file ca.pem \
    -storepass password \
    -keypass password

Inspect the keystore content:

keytool -list -keystore keystore.jks \
    -storepass password -v \
    -keypass password

Create the Kubernetes secret with the keystores:

kubectl create secret generic fips-tls \
    -n <namespace> \
    --from-file=keystore.bcfks=keystore.bcfks \
    --from-file=truststore.bcfks=truststore.bcfks \
    --from-file=keystore.jks=keystore.jks \
    --from-file=truststore.jks=truststore.jks \
    --from-literal=jksPassword.txt=password

Create the secret in the same namespace as the component CR that references it.

Configure FIPS-enabled Confluent Platform

To enable FIPS for the following components, add the settings below in each component custom resource (CR):

Kafka
KRaft
Schema Registry
Connect
ksqlDB

kind: <component>
spec:
  tls:
    fips:
      enabled: true   --- [1]
      mode: <fips-mode>   --- [2]       # Optional, CFK 3.2.0+
    secretRef:         --- [3]

[1] enabled is required and turns on FIPS support for the component.
[2] mode is optional and, in CFK 3.2.0 and later, controls the FIPS operation mode used by the component. Valid values are fips-140-2 and fips-140-3.
[3] secretRef is the name of the secret created in Create FIPS-compliant keystores.

For backward compatibility, the Kafka API to enable FIPS in CFK 2.5 through 2.8 (kafka.spec.fips) is still supported for Kafka in this release of CFK. As a best practice, use the current API as described above.

Warning

Azure Tiered Storage is not supported on FIPS-enabled CFK deployments because CFK does not provide Azure-specific TLS settings in FIPS mode, and the broker JVM truststore cannot be overridden to add the Azure storage CAs required for Azure Tiered Storage connectivity. This causes TLS failures when configuring Tiered Storage with Azure.