# 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](https://docs.confluent.io/operator/current/co-network-encryption.html#enable-dynamic-ak-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--kafka.`, and a hostname for each broker, `lkc--kafka.b.`, 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`: ```none 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.`) 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: - `-kafka..svc.` to `..svc.` - `-kafka-b..svc.` to `-...svc.` 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: ```none 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 `*..svc.` 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 - [Multi-Tenancy Overview](overview.md#multi-tenancy-overview) - [Deploy Ecosystem Components on a Multi-Tenant PKC](ecosystem-components.md#multi-tenancy-ecosystem-components)