This page extends the Apache Kafka security model to Kafka Connect. A worker authenticates to the Kafka cluster over a configured SASL_SSL/SSL listener exactly like any other client, so everything the core model says about authentication, authorization, and transport encryption to the brokers applies unchanged. What follows covers only what Connect adds on top — chiefly its own control plane, the REST API, and the fact that it runs user-supplied code.
plugin.path execute in the worker JVM with its privileges. Install only plugins you trust.connector.client.config.override.policy restricts it (see Authorization below).config.storage.topic, offset.storage.topic, and status.storage.topic; protect them with ACLs as you would any sensitive topic. In standalone mode, offsets are kept in a local file (offset.storage.file.filename) instead, so its protection is the host filesystem's responsibility.The REST API is configured with the listeners property (for example http://host:port or https://host:port); if unset it defaults to http on port 8083. In distributed mode the REST API is also the inter-worker transport — a request received by a follower is forwarded to the leader — so it is simultaneously a user-facing management interface and an internal control channel. rest.advertised.host.name, rest.advertised.port, and rest.advertised.listener control the URL other workers use to reach a node.
Operators should:
admin.listeners to separate the admin endpoints from the regular listeners, or set it to empty to disable them where they are not needed. If admin.listeners is not set, the /admin endpoints are attached to the default listeners.https listener so that both user traffic and inter-worker forwarding are encrypted.Connect enables no authentication on the REST API by default. There are two common ways to add it:
rest.extension.classes. The built-in BasicAuthSecurityRestExtension performs JAAS-based HTTP basic authentication against a configured LoginModule. The reference PropertyFileLoginModule is not intended for production, as it stores credentials in cleartext; production deployments should configure a LoginModule that authenticates against a real credential store.REST authentication only establishes who is calling; it does not, on its own, authorize that caller on a per-connector basis (see Authorization below). Separately, the worker's authentication to the Kafka brokers uses the standard ssl.*/sasl.* client configs described in the core model.
This is the weakest part of Connect's security posture, and operators must plan around it:
connector.client.config.override.policy defaults to All, so a connector configuration can override the worker's internal Kafka client settings. Since 4.2.0 it is recommended to set this to Allowlist (which becomes the default in 5.0) and permit only the keys you actually need. Overrides that load classes — such as sasl.jaas.config and sasl.login.class — are by design a code-execution vector, so only allow them when only trusted users can reach the REST API.The practical consequences are that you cannot grant Connect REST API access to anyone you would not trust as a cluster administrator, and if multiple distrusting users or teams need Connect you should give each its own Connect cluster rather than sharing one.
Two independent channels need TLS:
ssl.* client properties, exactly as in the core model.https listener. By default the REST server reuses the worker's ssl.* settings; to configure the REST endpoint independently of the Kafka client, use the listeners.https.* prefixed properties (when the prefix is used, the unprefixed ssl.* settings are ignored for the REST server). The same settings secure inter-worker forwarding in distributed mode.Connector configurations frequently contain credentials for external systems. As in the core model, reference them indirectly through a ConfigProvider rather than inlining them, and set allowed.paths on the file-based providers to constrain which directories they can read. Two Connect-specific caveats:
config.storage.topic as an ordinary Kafka record, and is therefore only as protected as that topic‘s ACLs and the brokers’ at-rest story. A ConfigProvider reference keeps the secret itself out of the topic — only the template string (${alias:fields}) is stored, not the resolved value. Note, however, that this does not hide the secret from REST API callers: anyone who knows a valid template string can usually retrieve the resolved value through the REST API.Connect loads connectors, converters, single-message transforms, predicates, ConfigProviders, and REST extensions from plugin.path. All of them run in the worker JVM with its full privileges, so installing a plugin is equivalent to granting it arbitrary code execution on the worker. Install only plugins from sources you trust, and treat the ability to influence which plugins load — or to set class-loading connector configs — as administrator-level access.
In line with the core model's classification, the following follow from Connect's design and are not, on their own, security vulnerabilities:
PropertyFileLoginModule storing cleartext credentials. The reference PropertyFileLoginModule shipped with the basic auth extension is documented as test-only; production deployments are expected to supply a real LoginModule. Its cleartext storage is therefore expected behaviour rather than a defect.