Confluent Developer Marketplace Get started
  1. Home
  2. Platform
  3. Confluent Private Cloud
  4. Multi-Tenancy

Configure TLS Certificates and DNS for Multi-Tenant PKCs

This page covers the TLS certificate options and DNS record requirements for routing client connections to Logical Kafka Clusters (LKCs) on a shared Physical Kafka Cluster (PKC). Use this information to choose the TLS approach that aligns with your organization’s security policy and target operational scale.

TLS certificate options

Every broker requires a valid TLS certificate for the LKC hostnames it serves. Choose one of two approaches for provisioning and maintaining broker certificates as you add LKCs:

  • Wildcard Subject Alternative Name (SAN) certificates: One certificate covers the bootstrap hostnames of all LKCs, and one wildcard SAN for each broker covers that broker’s LKC hostnames. For example, a PKC with two brokers needs *.mt.example.com, *.b0.mt.example.com, and *.b1.mt.example.com. A wildcard matches only one DNS label, so *.mt.example.com doesn’t match lkc-x7f2q9-kafka.b0.mt.example.com. Adding an LKC requires no certificate reissuance. Adding a broker requires adding that broker’s wildcard SAN. To avoid reissuing the certificate each time you add a broker, include wildcard SANs for the brokers you plan to add in the future. Confluent recommends this approach for high-density environments where you frequently add LKCs. Make sure the certificate you supply includes all of these SANs.

  • Per-LKC SAN certificates: Each LKC requires one SAN for its bootstrap hostname and one SAN for each broker. The LKC ID is assigned only when you create the LKC, so you can’t issue its certificate in advance. Adding an LKC requires reissuing the broker certificates. Choose this approach only if your organization’s security policy prohibits wildcard certificates and you plan to host a small number of LKCs on the PKC.

By default, rotating a broker certificate triggers a rolling restart of the brokers. To apply certificate updates without restarting brokers, enable dynamic certificate updates. This matters most with per-LKC SAN certificates, which you reissue for every new LKC. For more details, see Enable dynamic Kafka certificate update.

DNS setup for external listeners

Whichever TLS certificate approach you choose, you also need DNS records that route each LKC hostname to a broker.

Each LKC has a bootstrap hostname, lkc-<id>-kafka.<domain>, and a hostname for each broker, lkc-<id>-kafka.b<N>.<domain>, where b is the default broker prefix. Create a wildcard DNS record for each of the following, pointing to the corresponding load balancer:

  • Bootstrap wildcard record: Resolves the bootstrap hostname of every LKC, for example, *.mt.example.com, which matches lkc-x7f2q9-kafka.mt.example.com.

  • Broker wildcard record: Resolves the hostname of every LKC on one physical broker. Create one record for each broker, for example, *.b0.mt.example.com, which matches lkc-x7f2q9-kafka.b0.mt.example.com.

The following example lists the required DNS records for a two-broker PKC using the domain mt.example.com:

DNS name                Target
*.mt.example.com        Bootstrap load balancer
*.b0.mt.example.com     Broker 0 load balancer
*.b1.mt.example.com     Broker 1 load balancer

Note

Because each broker’s wildcard record (*.b<id>.<domain>) matches all present and future LKC hostnames routed to that broker, adding a new LKC requires no DNS updates. When you scale the PKC to add a broker, you must add a wildcard DNS record for the new broker, and the broker certificate must include the new broker’s wildcard SAN, unless you already included it.

DNS setup for in-cluster components

In-cluster components, such as Control Center and Kafka Connect, reach each LKC through in-cluster LKC hostnames. These hostnames don’t resolve by default, so configure your cluster DNS to resolve them as follows:

  • <lkc-id>-kafka.<namespace>.svc.<cluster-domain> to <kafka-name>.<namespace>.svc.<cluster-domain>

  • <lkc-id>-kafka-b<N>.<namespace>.svc.<cluster-domain> to <kafka-name>-<N>.<kafka-name>.<namespace>.svc.<cluster-domain>

Add two rewrite rules to the CoreDNS configuration for each PKC. Repeat this for each namespace that contains a multi-tenant PKC. The rules map every LKC hostname to the PKC’s own service names. Because the rules match any broker number, adding a broker to the PKC requires no DNS changes for in-cluster components.

The following example uses a PKC named pkc1 in the confluent namespace:

rewrite stop name regex ^lkc-[a-z0-9]+-kafka-b([0-9]+)\.confluent\.svc\.cluster\.local\.$ pkc1-{1}.pkc1.confluent.svc.cluster.local. answer auto
rewrite stop name regex ^lkc-[a-z0-9]+-kafka\.confluent\.svc\.cluster\.local\.$ pkc1.confluent.svc.cluster.local. answer auto

The internal listener certificate must include the *.<namespace>.svc.<cluster-domain> SAN. Certificates that CFK generates automatically include this SAN.

If you can’t modify cluster DNS, you can instead set spec.multiTenant.createTenantNameServices to true. CFK then creates Kubernetes Services for each LKC, which make the LKC hostnames resolvable.

Use this option only as a fallback. Confluent doesn’t recommend it, because these Services use IP addresses from the cluster’s Service IP range, and a large PKC can exhaust the range. For example, 100 LKCs on a six-broker PKC create 700 Services.

Related content