Docs Self-Managed Manage Kubernetes Networking and Connectivity Configure Listeners This is documentation for Self-Managed v24.1. To view the latest available version of the docs, see v24.2. Configure Listeners in Kubernetes You can fine-tune client interactions with Redpanda by customizing internal and external listener configurations. Anatomy of a listener Listeners are gateways for client communications in Redpanda. Redpanda uses TCP sockets for client connections, where each TCP socket consists of: IP address or DNS name: The unique network identifier of the Redpanda server. This can be a local address or a public address for cloud-based services. Port: A specific entry point for network traffic. Redpanda listens on designated ports for client connections. Clients must specify both the IP address or DNS name and port for a successful connection, such as 203.0.113.5:9093. The Redpanda Helm chart defines two listeners by default: Listener Description default Internal connections. These endpoints use internal addresses assigned to brokers by Kubernetes through the headless ClusterIP Service. external External connections. These endpoints are accessible through addresses configured in the external.domain and/or external.addresses settings in the Helm values. For example, these are the default settings for the internal Kafka API listener: listeners: kafka: port: 9093 authenticationMethod: tls: enabled: true cert: default listeners.kafka.port: The container port for internal client connections. listeners.kafka.authenticationMethod: The authentication method to use when the top-level auth.sasl.enabled setting is true. Default is sasl. listeners.kafka.tls.enabled: Whether TLS is enabled for this listener when the top-level tls.enabled setting is true for all listeners. listeners.kafka.tls.cert: The TLS certificates that this listener should use to secure client connections. TLS certificates are defined in tls.certs. These are the settings for the external Kafka API listener: listeners: kafka: external: default: enabled: true port: 9094 # -- If undefined, `listeners.kafka.external.default.port` is used. advertisedPorts: - 31092 tls: enabled: true cert: external # default is "sasl" authenticationMethod: listeners.kafka.external.default.port: The container port for external client connections. listeners.kafka.external.default.advertisedPorts: The node port that is routed to listeners.kafka.external.default.port. This port is opened in Kubernetes Services when external.service.enabled is true. listeners.kafka.external.default.authenticationMethod: The authentication method to use when the top-level auth.sasl.enabled setting is true. Default is sasl. listeners.kafka.external.default.tls.enabled: Whether TLS is enabled for this listener when the top-level tls.enabled setting is true for all listeners. listeners.kafka.external.default.tls.cert: The TLS certificates that this listener should use to secure client connections. TLS certificates are defined in tls.certs. Customize the external node ports Each listener has separate ports for internal and external connections. To customize the external node ports for each listener, replace <port> with the port that you want to use. Redpanda doesn’t validate the configured port numbers. Make sure to verify the following: Your configured port numbers are within the range that is assigned for node ports in your Kubernetes cluster. Your Kubernetes cluster is accessible through your desired node port range. You may need to edit your inbound firewall rules. Your configured port numbers are not in use by any other service. For the default ports, see the Redpanda Helm Chart Specification For example, to customize the node ports for the external Kafka API listener: custom-kafka-port.yaml listeners: kafka: external: default: advertisedPorts: - <port> Configure TLS certificates A Redpanda cluster provides granular control over the TLS certificates used by different listeners. This level of flexibility enables you to ensure the required level of security for each listener. For example, you can use a self-signed certificate for the internal RPC listener, while using a public certificate authority (CA) certificate for other listeners such as the Kafka API. Internal listeners: By default, all internal listeners use the self-signed certificate defined globally in the tls.certs.default configuration. To customize the certificates for each internal listener, you can edit the listeners.<listener-name>.tls.cert setting. External listeners: By default, all external listeners use the self-signed certificate defined globally in the tls.certs.external configuration. To customize the certificates for each internal listener, you can edit the listeners.<listener-name>.external.default.tls.cert setting. Here’s an example that configures two certificates: public-ca-cert: This certificate is configured with an Issuer managed by cert-manager. private-ca-cert. This certificate is configured with an Opaque Secret containing the tls.crt, tls.key, and ca.crt files. The external Admin API listener is configured with the public-ca-cert certificate. The internal Kafka API listener is configured with the private-ca-cert certificate, and the other listeners are configured with the default self-signed certificate. multiple-certs-tls.yaml tls: enabled: true certs: public-ca-cert: issuerRef: name: <issuer-name> kind: Issuer caEnabled: false private-ca-cert: secretRef: name: <secret-name> caEnabled: true default: caEnabled: true listeners: admin: external: default: tls: cert: public-ca-cert kafka: tls: cert: private-ca-cert http: tls: cert: default rpc: tls: cert: default schemaRegistry: tls: cert: default Disable external access You can disable external access for all listeners or for individual listeners. To disable external access for all listeners: disable-external-access.yaml external: enabled: false To disable external access for a specific listener, set listeners.<listener-name>.external.default to false. For example, to disable external access to the Kafka API listener: disable-external-kafka-api.yaml listeners: kafka: external: default: enabled: false Next steps Connect to Redpanda in Kubernetes Suggested reading Redpanda Helm Specification Redpanda CRD Reference Back to top × Simple online edits For simple changes, such as fixing a typo, you can edit the content directly on GitHub. Edit on GitHub Or, open an issue to let us know about something that you want us to change. Open an issue Contribution guide For extensive content updates, or if you prefer to work locally, read our contribution guide . Was this helpful? thumb_up thumb_down group Ask in the community mail Share your feedback group_add Make a contribution Connect to Redpanda External Access