Custom Domains and Network Isolation in Confluent Cloud Gateway

Confluent Cloud Gateway (Confluent Gateway) enables you to map Kafka listener endpoints to custom domains and isolate network traffic using private networking solutions. These capabilities enhance security, flexibility, and compliance for private Kafka clusters by allowing you to expose branded, abstracted endpoints to clients, restrict access according to your policies, and separate internal broker networks from external access.

Custom domain: Each custom domain is an isolated pathway, with its own entry point (endpoint), routing logic, and security enforcement mechanisms. By establishing and managing multiple custom domains, operators can create isolated network segments for different clients, departments, or applications, all controlled through the Gateway, removing the need for physical separation or complex client configuration.

Custom domains provide the framework for network isolation.

Custom domains can be configured using DNS records (for example, in AWS Route 53 or Azure Private Zones) or in the /etc/hosts file and mapped to the Gateway’s IP addresses. Use the /etc/hosts file option for local development purposes only.
Network isolation: When Kafka brokers reside in a private network, unreachable directly by external clients, Confluent Gateway acts as the proxy access point, enforcing controlled entry.

Both custom domains and network isolation help you enable external partner access for your Kafka clusters and data as per your compliance policies.

Set up custom domains and network isolation

To set up a custom domain and network isolation:

Set up host resolution for the custom domain.
Configure the Confluent Gateway to use the custom domain.
Restart the Confluent Gateway to apply the changes.

For a complete example of setting up network isolation with a custom domain, see the Gateway Images repository.

Set up host resolution for the custom domain

Set up host resolution for the custom domain. Ensure that network and DNS settings allow clients to resolve this custom domain to the Gateway’s actual IP address.

Kafka clients and the Confluent Gateway are in the same VPC

Create a private hosted zone or DNS zone in the VPC and create DNS records pointing to the private IP of the Confluent Gateway instance.

Kafka clients and the Confluent Gateway are in different VPCs

Enable connectivity between the VPCs using Peering, Transit Gateway, or Private Link.
Use the same private hosted zone or DNS zone, and associate it with both VPCs.
Create DNS records pointing to the private IP of the Confluent Gateway instance.

Kafka clients are on an external network

Create a public hosted zone or DNS zone.
Create DNS records pointing to the public IP of the Confluent Gateway instance.

For provider-specific instructions on creating a hosted zone or DNS zone, see:

Configure the Confluent Gateway to use the custom domain

Update your Confluent Gateway configuration so that the routes use the custom domain name as their endpoint.
```
routes:
  - name:
    endpoint:        --- [1]
```
- [1] Specify the same custom domain name you used in step 1 above, and specify the port.

Restart the Confluent Gateway to apply the changes

Restart the Confluent Gateway instance to apply the changes:

docker compose -f docker-compose.yaml up -d

or

kubectl apply -f <Gateway_CR.yaml>

The restart results in client disconnections and reconnections.

Example setup

This sample setup demonstrates how to use a private hosted zone in Route 53 to achieve custom domain routing and network isolation when both Confluent Gateway and Kafka clients reside in the same AWS VPC, and no public access is required.

Browse to AWS Console → Route 53 → Create Hosted Zone.
Select Private Hosted Zone, and enter your custom domain name (for example, mycluster-proxy-route53.kafka).
Associate the VPC where both Confluent Gateway and Kafka clients run (for example, vpc-0f2b932796e3e97a4).
Ensure the VPC has DNS Resolution and DNS Hostnames enabled.
Inside the hosted zone, create A records pointing to the private IP of the Confluent Gateway EC2 instance (10.0.3.140):
- mycluster-proxy-route53.kafka → 10.0.3.140
- *.mycluster-proxy-route53.kafka → 10.0.3.140
  
  This is needed when brokerIdentificationStrategy.type is host in gateway.yaml.

Modify the Confluent Gateway configuration file to use the custom domain.

The following is an example configuration using the sample values from the above steps:

Note

When using the host broker identification strategy, Confluent Gateway requires a security.ssl keystore to terminate TLS and read the client’s SNI header. If omitted, Confluent Gateway fails to start with GatewayConfigParseException: SSL keystore must be defined for host identification strategy. For more information, see SSL configuration.

streamingDomains:
  - name: sample-domain
    type: kafka
    kafkaCluster:
      name: kafka-cluster-1
      bootstrapServers:
        - id: SASL_SSL-1
          endpoint: <KAFKA_BROKER_HOST:PORT>
routes:
  - name: custom-domain-route
    endpoint: mycluster-proxy-route53.kafka:10000
    brokerIdentificationStrategy:
      type: host
      pattern: "broker$(nodeId).mycluster-proxy-route53.kafka"
    streamingDomain:
      name: sample-domain
      bootstrapServerId: SASL_SSL-1
    security:
      ssl:
        truststore:
          type: PKCS12
          location: /opt/ssl/client-truststore.p12
          password:
            file: /opt/secrets/client-truststore.password
        keystore:
          type: PKCS12
          location: /opt/ssl/gw-keystore.p12
          password:
            file: /opt/secrets/gw-keystore.password

Start the Confluent Gateway instance and test producing and consuming.