Cloudera Docs

Channel encryption (TLS) in Schema Registry

Get started with TLS encryption in Schema Registry. Learn which types of traffic you can secure with TLS, corresponding configuration properties, and recommended certificate management practices.

You can protect sensitive data and ensure secure access to Schema Registry by configuring TLS. TLS can be configured for the following types of traffic:

  • TLS for application traffic (backend/server-side) – Secures traffic between the external access point (LoadBalancer or Ingress) and Schema Registry. Ensures that even internal traffic within the Kubernetes cluster remains encrypted, protecting against potential threats inside the cluster network.

  • TLS for client traffic – Secures connections from end users (clients) to Schema Registry. Configured on the Kubernetes Service that provides external access (LoadBalancer or Ingress). Ensures that all data exchanged with external clients are encrypted.

  • TLS for OAuth – Secures connections between Schema Registry and your OAuth provider. Typically, you set this up when you configure OAuth authentication.

Cloudera recommends that you enable TLS for all of the above listed categories. This ensures that all traffic handled by Schema Registry is secure.

Configuring TLS channel encryption

Configure TLS with TLS-related properties in your custom values file. TLS for application, client, and OAuth traffic is configured separately.

TLS for application traffic

TLS for application traffic is configured with the tls.* properties. For example:

#...
tls:
  enabled: true
  keystore:
    secretKeyRef:
      name: [***KEYSTORE SECRET NAME***]
      key: [***KEYSTORE SECRET KEY***]
    password:
      secretKeyRef:
        name: [***KEYSTORE SECRET NAME***]
        key: [***KEYSTORE PASSWORD SECRET KEY***]
    type: PKCS12

  • tls.enabled – Enables or disables TLS for Schema Registry.

  • tls.keystore.secretKeyRef.* – The Secret name and Secret key that contain the keystore.

  • tls.keystore.password.secretKeyRef.* – The Secret name and Secret key that contain the keystore password.

TLS for client traffic

TLS for client traffic is configured on the Service (Ingress or LoadBalancer) that provides access to Schema Registry.

For Ingress, you configure ingress.tls.* properties. For example:

#...
ingress:
  enabled: true
  className: "nginx"
  rules:
    path: "/"
    host: "my-domain.example.com"
  tls:
    enabled: true
    secretRef: [***INGRESS TLS CERT SECRET***]
  extraAnnotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

TLS for Ingress is typically configured when you set up external access with Ingress. For a step-by-step guide see Configuring external access with Ingress.

For LoadBalancers, the actual load balancer is provisioned and managed by your cloud or infrastructure provider. As a result, TLS settings and certificate management may vary depending on the platform. Refer to vendor-specific documentation for detailed guidance on configuring TLS.

TLS for OAuth traffic

TLS for OAuth traffic is configured using the authentication.oauth.jwks.tls.* properties. These properties reference a Kubernetes Secret containing the truststore (PKCS12) of the root Certificate Authority (CA) of the OAuth certificate chain. You typically configure these properties when you set up OAuth, see Authentication in Schema Registry.

Managing certificates

Learn about managing TLS certificates for Schema Registry. You can manage certificates manually or use cert-manager to automate certificate management. Cloudera recommends automatic certificate management.

TLS certificates for Schema Registry are stored in various Secrets. The Secrets are specified by the following properties:

  • tls.keystore.secretKeyRef.name – The name of the Secret containing the TLS keystore used by Schema Registry.

  • ingress.tls.secretRef – The name of the Secret containing Ingress TLS certificates.

  • authentication.oauth.jwks.tls.truststore.secretKeyRef.name – The name of the Secret that contains the truststore for accessing the JWKS endpoint.

These Secrets must contain a valid certificate and private key. Cloudera recommends that you use cert-manager to manage the Secrets and the certificates that they store. Alternatively, you can choose to manage them manually.

Automatic certificate management with cert-manager

cert-manager is a popular Kubernetes add-on for automating the management and issuance of TLS certificates. In order to manage the certificates used by Schema Registry with cert-manager, you need the following:

  • A cert-manager instance in your Kubernetes cluster.

  • An Issuer deployed for cert-manager.

The management of the Secrets that Schema Registry uses to store certificates differs.

  • tls.keystore.secretKeyRef.name and authentication.oauth.jwks.tls.truststore.secretKeyRef.name – The Certificate resource for these Secrets must be created manually. When creating a Certificate resource, set spec.secretName to the names specified in these properties. This way cert-manager saves the certificates and private keys into the appropriate Secrets that Schema Registry expects.

  • ingress.tls.secretRef – The Certificate resource for this Secret is created automatically when the cert-manager.io/issuer: [***ISSUER NAME***] annotation is set in the ingress.extraAnnotations property.

    Specifically, the Ingress requests a certificate from cert-manager using the Issuer name from the annotation. This triggers the creation of the Certificate resource and saves the certificate file and private key to the Secret defined in ingress.tls.secretRef.

Manual certificate management

When managing certificates manually, you must create the Secrets that contain the certificates and private keys manually. Ensure that you create and update the appropriate Secrets.