Design the listener and security configuration for a broker that must serve internal services on a private network and external clients over the internet, with appropriately differentiated hardening.

**Goal.** One broker (or fleet) must serve two audiences with different trust levels: (a) internal microservices on a private VPC/subnet, and (b) external clients reaching in over the public internet. They need *different* hardening, so a single listener won't do. **Step 1 — Two named listeners.** Names describe roles; the four reserved names aren't enough because both segments need TLS but with different auth, so use custom names: ``` listeners=INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9094 ``` Bind to 0.0.0.0 (all local interfaces) — binding is fine on the wildcard. **Step 2 — Correct advertised addresses.** Each audience must receive an address *it* can route to (recall the bootstrap-then-metadata flow): ``` advertised.listeners=INTERNAL://kafka-1.internal:9092,EXTERNAL://kafka.example.com:9094 ``` Internal clients/brokers get the private hostname; external clients get the public DNS/LB name. Never advertise 0.0.0.0 or an internal name to the internet. **Step 3 — Per-segment protocol (the hardening matrix).** ``` listener.security.protocol.map=INTERNAL:SSL,EXTERNAL:SASL_SSL ``` - **INTERNAL → SSL with mTLS.** You own both ends and can issue certs from an internal CA, so mutual TLS gives strong, password-free identity. Set `listener.name.internal.ssl.client.auth=required`. - **EXTERNAL → SASL_SSL.** External principals are apps/users you authenticate with credentials or tokens, not certs you mint. TLS provides encryption; SASL provides identity. Choose **SCRAM-SHA-512** (salted, stored hashed) or **OAUTHBEARER** (OAuth2/OIDC tokens) over PLAIN. PLAIN is acceptable only because it's inside TLS, but SCRAM/OAUTHBEARER are preferred. **Step 4 — Isolate replication.** ``` inter.broker.listener.name=INTERNAL ``` Replication and broker coordination ride the trusted internal path (mTLS), off the internet-facing listener — better security and bandwidth isolation. (Set this OR security.inter.broker.protocol, never both.) **Step 5 — Per-listener configs.** Different keystores, mechanisms, and client-auth per listener via the `listener.name.<name>.*` prefix: ``` listener.name.internal.ssl.keystore.location=/certs/internal.keystore.jks listener.name.internal.ssl.client.auth=required listener.name.external.ssl.keystore.location=/certs/external.keystore.jks listener.name.external.sasl.enabled.mechanisms=SCRAM-SHA-512,OAUTHBEARER ``` **Step 6 — Defense in depth beyond Kafka.** - **Network controls:** firewall / security-group the EXTERNAL port (9094) to allowed source CIDRs; keep the INTERNAL port unreachable from the internet. - **TLS hygiene:** enforce TLS 1.2+/1.3, modern cipher suites (`ssl.enabled.protocols`, `ssl.cipher.suites`), and proper hostname verification (`ssl.endpoint.identification.algorithm=https`) so external clients verify the broker cert. - **AuthZ:** layer ACLs (or an authorizer) so authenticated external principals only touch their own topics/groups; mTLS-internal principals get broader rights. - **Quotas / throttling:** apply client/user quotas on the external listener to blunt abuse. **Why differentiate at all?** Internal traffic on a controlled network can use the cheaper, cert-based mTLS path and looser network rules; external traffic faces the hostile internet and needs credential/token auth plus tight network ACLs and quotas. Same broker, two hardening postures, expressed entirely through named listeners + the protocol map + per-listener configs. **Common pitfalls:** advertising the internal name externally (clients can't reach it); using one listener for both audiences (can't differentiate auth); pointing inter-broker at the external listener (exposes replication and adds internet latency); forgetting hostname verification on external clients (MITM risk); leaving SASL/PLAIN over a non-TLS listener.