How do you secure the Kafka Connect REST API with TLS and authentication, and what's the listeners.https configuration?

**Why this matters:** The Connect REST API (default port 8083) is how you create, reconfigure, pause, restart, and delete connectors — and it returns connector configs. Out of the box it is **HTTP, unauthenticated, unauthorized**: anyone who can reach the port has full control and can read configs. In any shared or production environment that's unacceptable. **1) TLS on the REST listener:** Connect's listener is configured with the `listeners` worker property, e.g. `listeners=https://0.0.0.0:8443`. You can list both http and https. For HTTPS you must give the server a certificate via listener-scoped SSL configs (note the `listeners.https.` prefix, which is separate from the `ssl.*` configs used to talk to *brokers*): ``` listeners=https://0.0.0.0:8443 listeners.https.ssl.keystore.location=/etc/connect/rest.keystore.jks listeners.https.ssl.keystore.password=... listeners.https.ssl.key.password=... ``` For **mutual TLS** (clients must present a cert), add: ``` listeners.https.ssl.truststore.location=/etc/connect/rest.truststore.jks listeners.https.ssl.truststore.password=... listeners.https.ssl.client.auth=required ``` `client.auth` can be `none`, `requested`, or `required`. **2) Authentication:** Connect has **no built-in user store**. Authentication is added through a *REST extension* — a pluggable `ConnectRestExtension` registered with `rest.extension.classes`. The bundled one is: ``` rest.extension.classes=org.apache.kafka.connect.rest.basic.auth.extension.BasicAuthSecurityRestExtension ``` This enforces **HTTP Basic** auth, validating credentials against a JAAS `LoginModule`. You point the JVM at a JAAS config (via `java.security.auth.login.config` system property) whose `KafkaConnect` entry uses, for example, `org.apache.kafka.common.security.plain.PlainLoginModule` or a `PropertyFileLoginModule` backed by a users file. So the flow is: extension → JAAS realm → user file/LDAP. **3) Authorization / RBAC:** Basic auth only proves *who* you are. To restrict *what* each user can do (e.g. read-only vs. create/delete connectors), you implement a custom `ConnectRestExtension`/JAX-RS filter or rely on a vendor distribution that adds RBAC. Vanilla Apache Kafka does not ship fine-grained REST authorization. **4) Distributed-mode interaction:** In a distributed cluster, a request landing on a non-leader worker is **forwarded** to the leader over the REST API. That inter-worker call must succeed under your TLS/auth setup — so the workers need to trust each other's certs and present valid credentials. Misconfiguring this breaks connector creation with forwarding errors. Set `rest.advertised.listener=https` and `rest.advertised.host.name`/`port` so peers address each other correctly. **5) Common production pattern:** Because vanilla auth is coarse, many teams put Connect behind a reverse proxy or API gateway (nginx, Envoy, an ingress) that terminates TLS, does authn/authz (OIDC, mTLS, API keys), and forwards to Connect on a private network — keeping the native listener simple while centralizing security. **Edge cases:** (a) the broker-facing `ssl.*` and the REST `listeners.https.ssl.*` are independent — securing one doesn't secure the other; (b) enabling `client.auth=required` without distributing client certs to peer workers breaks forwarding; (c) the REST API still echoes `${...}` placeholders, so externalizing secrets (ConfigProvider) complements REST auth to avoid leaking secrets via `GET /config`.