Configure Network Encryption for Confluent Platform Using Confluent for Kubernetes Blueprints

To secure network communications of Confluent components, Confluent for Kubernetes (CFK) Blueprints supports Transport Layer Security (TLS), an industry-standard encryption protocol.

This document describes how to configure TLS encryption and how to manage encryption certificates. For security concepts in Confluent Platform, see Security.

In CFK Blueprints, network encryption is not enabled by default. To have a secure deployment of Confluent Platform, encrypted network communication is always recommended. You can enable TLS encryption for Kafka listeners, REST interfaces for other components, and external services, such as LDAP, Proxy, and Confluent Cloud.

All the internal certificates between Confluent Platform components are managed by CFK Blueprints automatically. These certificates are configured via CFK Blueprints-managed certificate authority (CA) or user-provided CA. In this release, some components, namely Connect and Kafka REST Proxy, don’t have the capability to have different internal and external certificates.

The following types of TLS certificates are supported:

Auto-generated certificates

CFK Blueprints by default uses auto-generated certificates for internal and external communication. These auto-generated certificates are created either via user-provided CA or Blueprint-managed CA.

This is recommended if Confluent Platform components are configured without external access or in a private network.

User-provided certificates

If you need to enable access to Confluent services from an external-to-Kubernetes domain, it is recommended that you provide your own certificates.

This type of certificates are managed at the Blueprint level in the ConfluentPlatformBlueprint CR.

Use the following custom resources (CRs) to configure TLS and certificates:

  • CertificateStoreConfig CR

    A CertificateStoreConfig CR contains information about the CA and certificates.

    A CertificateStoreConfig has to be deployed before the ConfluentPlatformBlueprint and cluster CRs.

    One CertificateStoreConfig can only be used by one ConfluentPlatformBlueprint.

  • ConfluentPlatformBlueprint CR

    The confluentPlatformBlueprints CR defines the global certificate management strategy for all deployments. Each Deployment can override this at the deployment level for external communication.

  • Confluent cluster CRs, namely, ConnectCluster, ControlCenterCluster, KafkaCluster, KafkaRestProxyCluster, KsqlDBCluster, SchemaRegistryCluster, and ZookeeperCluster.

    These are also referred to as Deployment CRs in this document.

For external TLS communication, you can provide certificates in the ConfluentPlatformBlueprint CR or in the Confluent cluster CR. You specify the desired option in the ConfluentPlatformBlueprint CR (tlsConfig.providerType).

For internal communications among Confluent Platform components and Kafka brokers, CFK Blueprints auto-generates internal TLS certificates, using either auto-generated or user-provided CA. And CFK Blueprints takes care of the safe rolling of Confluent Platform when an internal certificate updates.

The high-level workflow to create certificates and enable TLS is:

To use auto-generated CA and auto-generated certificates:
  1. In the ConfluentPlatformBlueprint CR, configure for auto-generated CA.
  2. In the ConfluentPlatformBlueprint CR, configure for auto-generated certificates.
To use user-provided custom CA and auto-generated certificate:
  1. Have the custom CA you want to use.
  2. Create a Kubernetes secret containing the custom CA key pair.
  3. Create a CertificateStoreConfig CR with the reference to the secret created in the previous step.
  4. In the ConfluentPlatformBlueprint CR, configure for custom CA.
  5. In the ConfluentPlatformBlueprint CR, configure for auto-generated certificates.
To use user-provided server certificates:
  1. Have the custom CA you want to use.
  2. Create a Kubernetes secret containing the custom CA key pair.
  3. Create a CertificateStoreConfig CR with the reference to the secret created in the previous step.
  4. In the ConfluentPlatformBlueprint CR, configure for custom CA.
  5. Have the custom server certificates you want to use.
  6. Create a Kubernetes secret containing the custom server certificates.
  7. Create a CertificateStoreConfig CR with the reference to the secret created in the previous step.
  8. In the ConfluentPlatformBlueprint CR, configure for custom certificates.
  9. If you set the certificate provider type to Deployment in the previous step, configure the certificates in the cluster CRs.

Enable TLS

To enable TLS for Confluent Platform, set tlsConfig.providerType in the confluentPlatformBlueprints CR.

For configuration details for tlsConfig, see the subsequent sections.

  • For Kafka listers, namely, custom listeners, external listener, and internal listener:

    kind: ConfluentPlatformBlueprint
spec:
  confluentPlatform:
    kafkaListeners:
      customListeners:
        tlsConfig:                  --- [1]
          providerType:             --- [2]
      externalListener:
        tlsConfig:                  --- [1]
          providerType:             --- [2]
      internalListener:
        tlsConfig:                  --- [1]
          providerType:             --- [2]

  • For ZooKeeper:

    kind: ConfluentPlatformBlueprint
spec:
  confluentPlatform:
    zookeeper:
      tlsConfig:                  --- [1]
        providerType:             --- [2]

  • For other Confluent Platform components:

    kind: ConfluentPlatformBlueprint
spec:
  confluentPlatform:
    http:
      tlsConfig:                    --- [1]
        providerType:               --- [2]

  • [1] Add the tlsConfig section to enable TLS for the listeners/endpoints.

  • [2] Required. Specify where the TLS certificates are provided:

    • blueprint if you will provide the certificates in the Blueprint CR.
    • deployment if you will provide the certificates in the component cluster Deployment CRs.

Manage TLS certificates

This section describes how to manage keys and certificates that TLS relies on to establish trusted connections. Once configured, CFK Blueprints provides full certificates lifecycle management for Confluent Platform.

Configure certificate authority key pair

Configure a certificate authority (CA) that will sign the certificates.

  1. If using a custom CA key pair:

    1. Create a Kubernetes secret that contains the CA key pair:

      kubectl create secret tls <secret name> \
  --cert=/path/to/ca.pem \
  --key=/path/to/ca-key.pem \
  --namespace <namespace>

    2. Create a CertificateStoreConfig CR with the reference to the secret created in the previous step.

  2. Configure the CA in the ConfluentPlatformBlueprint CR:

    kind: ConfluentPlatformBlueprint
spec:
  internalCAKeyPair:            --- [1]
    providerType:               --- [2]
    blueprint:
      type:                     --- [3]
      auto:
        caConfig:               --- [4]
          certDurationInDays:   --- [5]
          renewBeforeInDays:    --- [6]
          sans:                 --- [7]
        certificateConfig:      --- [8]
          certDurationInDays:   --- [9]
          renewBeforeInDays:    --- [10]
          sans:                 --- [11]
      custom:                   --- [12]
        certificateConfig:      --- [13]
          certDurationInDays:   --- [14]
          renewBeforeInDays:    --- [15]
          sans:                 --- [16]
        certificateStoreConfig
          name:                 --- [17]

    • [1] Required. Even when using user-provided certificates, this section is used to generate internal certificates for Confluent Platform component.

    • [2] Required. Specify where the CA key pair is specified. Set to blueprint.

    • [3] Specify if the CA is auto-generated by CFK Blueprints (auto) or user-provided (custom).

    • [4] Specify CA lifecycle management info in this section.

    • [5] Set to the number of days for which the auto-generated CA key pair is valid. The default is five years.

    • [6] Set to the renewal time for auto-generated CA key pair. The default is 30 days.

    • [7] SANs to be added for all auto-generated CA key pair CFK Blueprints. Use this only for adding wild card SANs.

      Modifying this setting will roll all Confluent clusters and will regenerate the certificates for all Confluent Platform clusters managed by CFK Blueprints.

    • [8] Specify lifecycle management info for the auto-generated certificates in this section.

    • [9] Set to the number of days for which the auto-generated certificates are valid. The default is one year.

    • [10] Set to the renewal time for auto-generated certificates. The default is 30 days.

    • [11] SANs to be added for all auto-generated certificates|. Use this only for adding wild card SANs.

      Modifying this setting will roll all Confluent clusters and will regenerate the certificates for all Confluent Platform clusters managed by CFK Blueprints.

    • [12] Required if [1] (type) is set to custom.

    • [13] Specify lifecycle management info for the user-provided certificates in this section.

    • [14] Set to the number of days for which the custom certificates are valid. The default is one year.

    • [15] Set to the renewal time for custom certificates. The default is 30 days.

    • [16] SANs to be added for all custom certificates. Use this only for adding wild card SANs.

    • [17] Required if [1] (type) is set to custom. The certificate store that you created in the previous step to hold the CA key pair.

Use auto-generated TLS certificates

You can use auto-generated certificates to encrypt internal and external Confluent Platform communications. With the CA you provided or auto-generated, CFK Blueprints automates provisioning, securing, and operating certificates for internal networking communications.

  1. Configure CA.

  2. In the confluentPlatformBlueprints CR, specify that the TLS certificates are provided in the Blueprint.

    To use auto-generated certificates, do not specify tlsConfig.certificateStoreConfig.

    • For Kafka listers, namely, custom listeners, external listener, and internal listener:

      kind: ConfluentPlatformBlueprint
spec:
  confluentPlatform:
    kafkaListeners:
      customListeners:
        tlsConfig:                  --- [1]
          providerType: blueprint   --- [2]
      externalListener:
        tlsConfig:                  --- [1]
          providerType: blueprint   --- [2]
      internalListener:
        tlsConfig:                  --- [1]
          providerType: blueprint   --- [2]

    • For ZooKeeper:

      kind: ConfluentPlatformBlueprint
spec:
  confluentPlatform
    zookeeper:
      tlsConfig:                    --- [1]
        providerType: blueprint     --- [2]

    • For other Confluent Platform components:

      kind: ConfluentPlatformBlueprint
spec:
  confluentPlatform:
    http:
      tlsConfig:                    --- [1]
        providerType: blueprint     --- [2]

    • [1] Set the tlsConfig to enable TLS for the listeners/endpoints.

    • [2] Required. Specify where the TLS certificates come from. Set to blueprint to use auto-generated certificates.

Use user-provided TLS certificates

When you provide custom TLS certificates, CFK Blueprints takes the provided files and configures Confluent components accordingly.

You are responsible for managing user-provided certificates.

The information about a certificate is available on /status of the cluster CR.

Any certificate changes will trigger safe rolling, including impacted dependencies Confluent components. Use extra care when changing Kafka certificates as it impacts all dependent Confluent components.

Create a custom certificate secret

For user-provided custom certificates, the following TLS certificate information must be provided for each Confluent component:

  • The component’s server private key
  • The component’s server certificate (public key)

Create a Kubernetes secret with the certificate information for each component:

kubectl -create secret generic <secret-name> \
  --from-file=tls.key=<path to the server private key for the component> \
  --from-file=tls.crt=<path to the server certificate for the component> \
  --namespace <namespace>

Provide custom TLS certificates in the Blueprint

To provide your custom certificates in the ConfluentPlatformBlueprint CR:

  1. Configure CA.

  2. Create a certificate secret.

  3. Create a CertificateStoreConfig CR with the reference to the secret created in the previous step.

  4. Provide the custom certificates in the ConfluentPlatformBlueprint CR.

    • For Kafka listers, namely, custom listeners, external listener, and internal listener:

      kind: ConfluentPlatformBlueprint
spec:
  confluentPlatform:
    kafkaListeners:
      customListeners:
        tlsConfig:                  --- [1]
          providerType:             --- [2]
          blueprint:                --- [3]
            certificateStoreConfig: --- [4]
              name:                 --- [5]
      externalListener:
        tlsConfig:                  --- [1]
          providerType:             --- [2]
          blueprint:                --- [3]
            certificateStoreConfig: --- [4]
              name:                 --- [5]
      internalListener:
        tlsConfig:                  --- [1]
          providerType:             --- [2a]
          blueprint:                --- [3]
            certificateStoreConfig: --- [4]
              name:                 --- [5]

    • For ZooKeeper:

      kind: ConfluentPlatformBlueprint
spec:
  confluentPlatform
    zookeeper:
      tlsConfig:                    --- [1]
        providerType:               --- [2a]
        blueprint:                  --- [3]
          certificateStoreConfig:   --- [4]
            name:                   --- [5]

    • For other Confluent Platform components:

      kind: ConfluentPlatformBlueprint
spec:
  confluentPlatform:
    http:
      tlsConfig:                    --- [1]
        providerType:               --- [2]
        blueprint:                  --- [3]
          certificateStoreConfig:   --- [4]
            name:                   --- [5]

    • [1] Set tlsConfig to enable TLS for the listeners/endpoints.

    • [2] Required. Specify where the TLS certificates come from:

      • blueprint if you will provide the certificates in the Blueprint CR.
      • deployment if you will the certificates in the component cluster Deployment CR.

    • [2a] Required. For the internal listener, only blueprint is allowed because internal TLS is managed by the Blueprint.

    • [3] If [2] (providerType) is set to blueprint, this is required. Specifies that the Blueprint provides TLS certificates configuration.

    • [4] Specify the section to provide your own custom certificates.

    • [5] Specify the name of the CertificateStoreConfig CR that you created in the previous step.

Provide custom TLS certificates in the Deployment

To provide your custom certificates in a Confluent cluster CR:

  1. Configure CA.
  2. Create a certificate secret.
  3. Create a CertificateStoreConfig CR with the reference to the secret created in the previous step.

  • For Kafka listers, namely, custom listeners, external listener, and internal listener, set the following in the KafkaCluster CR:

    kind: KafkaCluster
spec:
  externalAccess:
    kafkaListeners:
      listeners:
        custom:
          tlsConfig:
            certificateStoreConfigRef:
              name:                    --- [1]
              namespace:               --- [2]
        external:
          tlsConfig:
            certificateStoreConfigRef:
              name:                    --- [1]
              namespace:               --- [2]

  • For other Confluent Platform components, set the following in the component cluster CR, for example, ConnectCluster or KsqlDBCluster CR:

    kind: <component>Cluster
spec:
  externalAccess
    tlsConfig:
      certificateStoreConfigRef:
          name:                        --- [1]
          namespace:                   --- [2]

  • [1] Required. Specify the name of the CertificateStoreConfig CR that contains the certificates.

  • [2] Specify the namespace of the CertificateStoreConfig CR that you created in the previous step.

Create a certificate store

To inject custom certificates, create a CertificateStoreConfig CR:

kind: CertificateStoreConfig
metadata:
  name:                          --- [1]
  namespace:                     --- [2]
spec:
  sourceType: kubernetes         --- [3]
  kubernetes:                    --- [4]
    type: secret                 --- [5]
    secret:
      name:                      --- [6]
  • [1] Required. Name of this certificate store.
  • [2] Namespace for this certificate store.
  • [3] Specify how the certificates are stored. Kubernetes secret is supported.
  • [4] Required when [3] is set to kubernetes.
  • [5] Specify to use a Kubernetes secret to store your custom certificates.
  • [6] Provide the secret that contains your custom certificates.

Update a certificate store

If a CertificateStoreConfig CR name is updated, CFK Blueprints will roll the appropriate Confluent Platform components.

If any content in a CertificateStoreConfig CR changes, you need to manually restart the clusters that use the CertificateStoreConfig CR. Apply the following annotation to the cluster deployment CR that uses the updated certificate:

kubectl annotate <CR type> <CR name> -n <namespace> cpc.platform.confluent.io/force-roll=”true”

Delete a certificate store

You cannot delete a CertificateStoreConfig CR if the CR is referenced by any CFK Blueprints object, such as a Blueprint CR.