Why Kafka Connect securing starts with the REST API
The code-execution risk in a self-hosted Kafka Connect cluster comes from two surfaces: the Connect REST API, which accepts connector configurations over HTTP, and client config overrides, which let a connector change the settings of the producers and consumers it runs. Anyone who can reach that API and shape a connector config may be able to make the workers run code they should not, so this is the first control to close. Teams need it most when one Connect cluster serves several teams, when multiple groups deploy their own connectors, or when the flows carry regulated data that a shared worker should not expose. MirrorMaker 2 runs on Connect too, so the same reasoning applies to replication clusters.
Kafka's security overview confirms what the platform provides: clients, brokers and tools authenticate over SSL or SASL, and authorization is pluggable. Those controls establish who the worker is when it talks to the cluster. They do not, on their own, decide who may call the REST API or which overrides a submitted config may set, so confirm the Connect settings for that in the documentation for your version. On the broker side, the StandardAuthorizer keeps ACLs in the metadata log, and resources without ACLs are limited to super users unless allow.everyone.if.no.acl.found is set to true. Read the Kafka authorization and ACLs documentation and make sure the worker principal holds only the access its internal and connector topics need.
Start with four decisions: who may deploy connectors, which plugins are trusted enough to install, which principal each worker runs as, and where the REST listener is reachable from. Then verify the result. Using a low-privilege account, submit a connector config that attempts an override outside your policy, confirm the request is refused, and note where the event is logged. Keep that output with your change records, because the question a security reviewer will ask is who could have changed a connector and how you know they could not do more.
How the controls layer on each other
The Connect REST API lets callers create, change, pause, restart and delete connectors. A connector configuration names the classes the worker will load and the settings it will run with, so anyone who can reach the API can submit code paths and configuration to the worker. Restricting access to the REST listener is the first layer, and the later controls assume that only approved operators can submit configuration at all. Confirm the exact listener, TLS and authentication property names for your version in the 4.3 Connect documentation before writing them into worker configuration.
- What it blocks: Callers outside the approved management network, and callers who cannot authenticate to the REST listener.
- What it does not block: An authorized operator who submits a harmful or careless connector configuration. Access restriction narrows who can ask, not what they ask for.
- Listener scope: Bind the REST listener to management interfaces only, and keep it off application, user-facing and public networks.
- Transport: Serve the REST API over TLS so credentials and connector configuration are not exposed on the management network.
- Intermediaries: Include any load balancer, ingress or sidecar in the review, since each one can widen reachability.
Check that a scan from application subnets cannot reach the REST port and that the operator network is the only path to it.
Connectors can set override values for the client configuration the worker uses for its producers, consumers and admin clients. The client config override policy decides which of those keys a connector is allowed to change. An allowlist limits which keys can be overridden, so it protects the worker's client settings from changes such as redirecting connections, but it does not evaluate every value a permitted key can take. Confirm the policy class names and the worker property that selects them in the 4.3 Connect documentation.
- What it blocks: Connector-level overrides of client keys that the policy does not permit, including security and connection settings that the platform team manages.
- What it does not block: Unsafe values for keys that are permitted, or plugin code that opens its own connections without going through the client override path.
- Permitted keys: Keep the permitted list short and reviewed, and add a key only when a pipeline has a documented need for it.
- Explicit setting: Set the policy in the worker configuration and do not depend on the default value.
- Consistency: Apply the same policy to every worker in the group, since a single worker with a looser setting weakens the whole group.
Check the effective policy on each worker and test that a connector submitting a disallowed key is rejected.
Connect loads connector, converter, transformation and predicate classes from the directories listed in the worker's plugin path. Any class on that path runs inside the worker process with the worker's network reach and credentials. The override policy does not sandbox plugin code, and class loading isolation separates dependencies so that versions do not collide. It should not be treated as a security boundary. The control in this tab is therefore about what gets installed, where it comes from, and who can write to the plugin directories.
- What it blocks: Plugins that were never reviewed, copied in by hand, or placed by a process with broader write access than the platform team holds.
- What it does not block: A vetted plugin that contains a vulnerability, or a trusted plugin configured to reach systems it should not reach.
- Plugin path: Limit the plugin path to directories the platform team owns, and make them read-only for the account that runs the worker.
- Artifact provenance: Install only builds that are pinned to a version, verified against a published checksum, and recorded with their source.
- Upgrade review: Treat each plugin version change as a change request that repeats the same review.
Check file ownership and permissions on every plugin directory on every worker, and compare the installed inventory with the approved list.
Workers authenticate to the cluster as a principal, and that identity needs ACLs to use the internal topics, consumer groups and the topics that carry connector data. With the StandardAuthorizer in KRaft clusters, ACLs are stored in the metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. The worker's grants therefore define what a misused connector can reach through the worker identity. The authorization and ACL documentation covers the model in detail.
- What it blocks: A connector using the worker identity to read or write topics, groups or internal state outside the grants that pipeline needs.
- What it does not block: Access to topics the worker principal was legitimately granted, so grants should match the minimum each pipeline requires.
- Separate identities: Use distinct principals for the worker, for operators and, where your version supports it, for connector-level clients, so logs and ACLs can separate them. Confirm the options in the 4.3 documentation.
- Super users: Keep the super user list minimal and keep it out of day-to-day connector and operator use.
- Default access: Confirm that allow.everyone.if.no.acl.found is not set to true in production.
Review the ACL list for each worker principal and confirm that topics outside the pipeline return access denied.
Which control fits which Connect setup
This table compares the controls that limit who can change Kafka Connect and what a connector can make a worker do. Read each row as a layer: the middle columns show what a control blocks and what it costs to run, and the last column shows when it fits. The main takeaway is that network restriction and override policy address different risks, so most clusters need more than one.
| Option | What it protects against | Trade-off | When it fits |
|---|---|---|---|
| Network-restricted REST access | Unknown hosts submitting or changing connectors over the REST port | Does not stop a caller already inside the allowed network or on an allowed host | Every Connect cluster as a baseline, especially where only a pipeline host needs access |
| Authenticated REST access | Anonymous or unidentified changes to connectors, and no record of who made them | Adds identity setup and credential handling for pipelines; confirm the options your version supports | Shared clusters where several teams submit or change connectors |
| Allowlist override policy | A connector config redirecting worker client settings or setting unsafe client properties | Each new legitimate override needs a list change and review, so some connectors fail until updated | Clusters where connector owners need some client tuning but should not set everything |
| No override policy | The widest class of override abuse, since connectors cannot change worker client settings | Connectors needing client changes must rely on worker-level settings, which needs coordination | Clusters where connector owners are not trusted to set client properties |
| Trusted plugins only | Arbitrary code loaded from the plugin path and run inside the worker | Connector upgrades need a build, review and rollout cycle before they reach the cluster | All clusters, since a connector plugin runs with the worker's privileges |
| Worker principal with scoped ACLs | A compromised worker or connector reading or writing topics and groups outside its scope | ACLs must be maintained per connector, and a missing grant stops the worker | Clusters where the authorizer is enabled and connectors touch different topics |
| Shared Connect cluster | Nothing on its own; it keeps one team's plugins, overrides and principal close to another's | Lower overhead, but one override policy, plugin set and principal apply to every team | One trust domain with one owning team and similar data classification |
| Dedicated Connect cluster per trust zone | Cross-team access, plugin contamination and shared worker credentials | More infrastructure to deploy, patch and monitor for each cluster | Teams with different data classification, trust levels or change schedules |
How to lock down a Connect worker step by step
This sequence closes the paths through which a Connect worker can be made to load code or accept settings it should not. It starts with an inventory, then narrows who can reach the REST API, limits which client settings connectors can override, controls which plugins load, and gives the worker its own scoped identity. It ends with tests that show each control refuses what it should refuse.
Inventory plugins and REST callers
The platform owner lists every plugin directory on each worker (the paths set by plugin.path), every connector currently deployed, and every system or person that calls the REST API, including CI jobs, dashboards and scripts. For each item, record an owner and a business purpose. This step is done when the list is written down, and every plugin and caller on it can be explained. Anything without an owner is flagged for removal or review before the later steps begin.
Restrict the REST listener to approved networks
The platform team binds the worker REST listener to an internal interface through the listeners setting and allows inbound connections only from the management hosts and deployment pipeline that the inventory approved. If a proxy fronts the API, it must enforce authentication and must not forward requests from other sources. Check that a connection to the REST port from an unapproved host fails at the network layer, and that an approved host receives a normal response from the worker. Confirm the authentication behavior for your Connect version in its documentation.
Set the client config override policy
The platform team sets the connector client config override policy on every worker to the Allowlist policy in the security plan, and lists only the client settings that approved connectors need to override. The policy must be identical on all workers, because a connector accepted by one worker and rejected by another causes hard-to-diagnose failures. Confirm the exact configuration key and policy class name against the Connect documentation for your release. Check that the value matches across every worker configuration file and that the policy appears in the worker's startup logs.
Approve and install only trusted plugins
The platform team installs connector plugins from a reviewed artifact list into the directories named in plugin.path. Each artifact is recorded with its checksum and a named approver, and the team removes unused connectors and any plugin the inventory cannot attribute to an owner. Workers are restarted or reloaded through the normal deployment process. Check that the connector plugin list returned by the REST API matches the approved list exactly, with no extra entries.
Create a dedicated worker principal with scoped ACLs
The security or platform team creates a service principal for the Connect worker, separate from any application or administrator account, and authenticates it with the mechanism chosen in the listener design. The principal receives literal or prefixed ACLs on the config, offset and status topics named in the worker configuration, on the Connect cluster group, and on the connector topics it reads or writes. With the StandardAuthorizer, resources without ACLs are limited to super users unless allow.everyone.if.no.acl.found is true, so confirm that setting is not enabled. Check that the ACL listing for the principal contains only those entries and that the worker starts and runs a test connector.
Verify with out-of-policy and unauthorized requests
The tester submits a connector configuration that sets a client override outside the Allowlist and confirms the REST call is rejected with an error from the worker. The tester then sends a REST request from an unapproved host, and another without the approved identity, and confirms both are refused. Both tests are repeated after every plugin change or policy change. The sequence is complete when both attempts fail, the rejections appear in the worker logs, and the test results are stored with the change record.
Operational risks that remain after the controls are in place
The Connect REST API controls close the most direct route to code execution, but several risks persist through routine operation. Each card below names one of them, why it matters for this Connect setup, and what to check on a running cluster.
Plugin supply chain and version pinning
Connect loads connector plugins from directories on the worker's plugin path, so whatever jar lands there runs with the worker's privileges. Pin each plugin to a reviewed artifact version, record its checksum, and restrict who can write to the plugin path. Confirm that the Connect worker's plugin path is read-only for everyone except the deployment pipeline, and that a rollback to a known plugin version is documented before the next change window.
Override drift as connectors are added
The Allowlist policy is only as strong as the list. Each new connector type tends to add another client config key to the allowlist, and over time the list grows past what anyone reviewed. Keep the allowlist in version control, require review for every addition, and compare the live worker configuration against the approved file on a schedule.
Over-broad worker ACLs
Worker principals often receive wide topic and group permissions during setup so that connectors start without errors. In KRaft clusters, the StandardAuthorizer keeps these ACLs in the metadata log, and resources without ACLs are limited to super users unless allow.everyone.if.no.acl.found is set to true. Review each worker principal's grants against the internal topics and the topics its connectors actually use, and confirm that this setting is not enabled as a shortcut.
Audit logging of REST changes
Connector creation, reconfiguration and deletion through the REST API change what data flows and where it goes, yet Kafka's own logs do not record who made each change unless the API sits behind a logging layer. Decide where REST requests are logged, who reviews them, and how long records are kept. Confirm that a change to a connector's config can be traced to a named identity and a time.
Credential handling in connector configs
Connector configurations often carry database passwords, API tokens and keystore paths. Once submitted through the REST API, these values are stored in the Connect configuration topics and can appear in worker logs or API responses if they are not handled deliberately. Use config providers that resolve secrets at runtime, keep plaintext out of submitted JSON, and verify that GET responses and logs do not echo sensitive fields.
Patching Connect alongside brokers
Connect runs as its own process with its own dependencies, so a broker upgrade does not patch the workers. Schedule Connect worker upgrades in the same maintenance plan as brokers, and track security releases for both. Confirm which Kafka release your workers run, check the supported release list before each upgrade window, and test a worker upgrade against a non-production cluster first.
Questions teams ask before securing Connect
Can our team secure Kafka Connect internally without a partner?
Yes, if you already run Kafka and have people who understand Connect workers, ACLs and plugin packaging. The work is mostly configuration and access design, not new software, because Apache Kafka is released under the Apache License 2.0 with no paid edition from the project itself. The harder part is coordination: Connect admins, Kafka admins and a security reviewer must agree on who may call the REST API, which plugins are trusted and which worker principals get which ACLs. Teams without a Kafka admin or a reviewer often find that gap is the real cost, so ask an outside partner to scope it if those roles are thin.
What makes the effort for Connect security grow or shrink?
Effort rises with the number of connectors, the number of plugins installed on the workers, whether the cluster is shared between teams, and how mature your existing ACL model is. Each connector may need its own worker principal and ACLs, and each plugin needs a review before it is trusted. A shared cluster adds tenant isolation questions. A clean, prefixed ACL model already in place reduces the work. Ask any quote to list each of these inputs and state how many connectors, plugins and clusters it assumes.
What do we need to provide during a Connect security engagement?
Expect to supply three roles. Connect admins own worker configuration, plugin deployment and the REST API endpoints. Kafka admins own the authorizer, ACLs and broker listeners. A security reviewer approves the access model and the list of trusted plugins. You also provide an inventory of connectors, their owners and the systems they reach, plus access to test clusters. Ask the quote to name which of these roles are yours and which are provided by the partner.
What drives the time and cost of a Connect security project?
Cost is one-time for the design, the rollout and the test plan, and it recurs whenever you add connectors, install new plugins or upgrade Kafka. The main drivers are the connector count, the plugin inventory, the number of teams sharing the cluster and the state of your current ACLs. Ask for the quote to separate fixed scope from optional items, such as a review of each plugin's source or ongoing checks after upgrades. DeployOpen does not publish a price list, so the written scope determines the figure.
Does Kafka Connect security require Kafka 4.x and KRaft?
No, you do not need Kafka 4.x to apply these controls, but the choice affects the design. Apache Kafka 4.0 supports only KRaft mode and removed ZooKeeper mode, so a ZooKeeper-based cluster must migrate to KRaft before upgrading to 4.x. The Kafka upgrade notes also recommend that KRaft clusters older than 3.3.x upgrade to 3.9.x before moving to 4.x. Since Kafka 4.0, brokers, Kafka Connect and tools require Java 17. Check the supported releases on the downloads page before you pick a target version, and confirm with your platform team which version your Connect workers will run.
How do we test that Connect is locked down?
Test each control separately. Confirm that the REST API rejects unauthenticated requests and that only approved administrators can create or change connectors. Check that the Allowlist client config override policy blocks any override outside the approved list, and that workers can reach only the topics and ACL-permitted resources they need. Verify that plugins not on the trusted list cannot load. Repeat these checks after each Kafka upgrade or plugin change. Penetration testing can cover the Connect REST API as part of a wider scope, and you should ask a tester to attempt override injection and unauthorized connector creation.
Which Connect risks should the security review cover first?
The highest-risk items are the REST API, client config overrides and plugins. Anyone who can create or edit connectors can change worker behavior, so the REST API must be restricted to named administrators over authenticated, encrypted channels. Overrides must go through an Allowlist policy. Plugins should come only from sources your security team has approved. Worker principals should hold only the ACLs they need, and super user rights should not be granted to them. Treat these as the first review items before the rest of the hardening checklist.
What to confirm in your own environment
The research behind this page does not settle every setting or behavior you will depend on. The cards below list the items to check against the Kafka 4.3 documentation and in your own test cluster before you rely on them in production. Each one affects whether the Connect REST API and connector overrides stay closed to untrusted input.
Exact Connect REST and override property names
Confirm the REST endpoints, the override policy property name and its accepted values for the Kafka release you run. Property names and defaults can change between releases, so a configuration copied from an older example may silently not apply. Check the exact keys in the 4.3 documentation and verify them by sending an override that should be rejected and confirming the worker refuses it.
Plugin isolation behavior
Find out how your workers load connector plugins, whether plugin isolation is enabled, and which classes are shared with the worker classpath. Isolation limits what one connector can reach, but it is not a sandbox for hostile code. Treat any plugin you install as trusted code and test which resources a connector can read from the worker host.
Allowlist coverage for your connectors
Confirm that the Allowlist override policy covers every client configuration property your connectors use, including security and class-loading settings. A property missing from the list may be blocked, which breaks the connector, or a property you did not intend to permit may pass. Compare the allowed set against each connector's documented configuration and record the decision for each one.
Worker principals and ACL scope
Verify which Kafka principal each Connect worker uses and what its ACLs allow on the internal topics, the group and the connector topics. A worker principal with broader rights than it needs turns a connector configuration change into access to other topics. Confirm the scope in the Kafka authorization documentation and check it with a test principal that should be denied.
Identity provider to Kafka principal mapping
Check how the subject or claim from your identity provider becomes a Kafka principal, especially if a connector or operator logs in through SSO or OAuth. A mapping rule that accepts more claims than intended can grant a person or service rights they should not hold. Test the mapping with real tokens from each client type and confirm the resulting principal name appears in your ACLs.
Your own REST exposure and test results
Confirm which network paths reach the Connect REST listener, including load balancers, ingress rules and monitoring tools that may call it. Run an authenticated and an unauthenticated request from each path and record the result. Keep these tests in your regression suite so that a later upgrade or proxy change that reopens the API is caught before production.
How to prove the Connect controls work
The controls on the Connect REST API and connector overrides are only worth something if you can show they fail closed. Start with negative tests, run from a host outside the approved management network and from a host inside it using an unprivileged account. Attempt unauthenticated and under-privileged calls to the Connect REST API, including requests to create or update connectors that carry a connector.client.config.override.policy value outside your intended setting, and attempts to override client settings such as bootstrap servers or security properties through connector configuration. Each attempt should be rejected and logged. Repeat the same tests after every worker configuration change, plugin change and Connect upgrade, because a settings change can silently reopen a path that was closed.
Next, compare the plugin inventory on each worker with the approved list your team signed off. Record the plugin directories configured through plugin.path, the jar files and versions actually loaded, and the connector classes the REST API reports as available. Any plugin present on a worker but absent from the approved list is a finding, even if no connector uses it yet, since its code can run as soon as someone creates a connector of that type. Confirm the approved list is versioned and that the inventory check runs on a schedule, not only at go-live.
Then review the worker principal and its ACLs. Confirm which principal the Connect workers use to reach the brokers, that it holds only the topic, group and cluster permissions its internal topics and connectors need, and that no human or application account shares it. Under the StandardAuthorizer, resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so verify that setting is not enabled on your clusters. Check the authorization documentation against your version before you rely on any default. Keep the ACL listing, the test scripts, their results and the change records together as retained evidence. DeployOpen prepares this evidence for your controls, but independent auditors and certification bodies issue any audit report or attestation, and the scope of what they accept is theirs to set.
How DeployOpen scopes and delivers Connect security
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Kafka Connect, that means fixing the REST API exposure, the connector override policy, the plugin inventory and the worker principals together, then handing over evidence your team can keep current.
How we scope
- Inventory every Connect cluster, its REST listener addresses and which networks can reach them today.
- Agree in writing which override policy, plugin sources and worker principals are in scope.
- Define the acceptance tests and the evidence each control must produce before work starts.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before any work begins.
How we build
- Restrict the REST API to management networks and the operators who need it, with authenticated access.
- Configure the Allowlist client config override policy and the connector class allowlist, then test blocked overrides.
- Install only reviewed plugins from trusted sources, and record each plugin version and checksum.
- Create one worker principal per cluster with ACLs limited to its internal topics and group IDs.
How we hand over
- Deliver configuration as code, with the override policy, listener settings and ACL definitions versioned.
- Provide a runbook for adding a plugin, changing an allowlist entry and rotating worker credentials.
- Document the test cases, their results and the reasons each control was set, for your auditors and reviewers.
- Walk your platform and security teams through the handover and the evidence they need to rerun checks.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Review Connect configuration and ACLs when new connectors, plugins or Kafka releases are introduced.
- Re-run the override and REST API tests after each upgrade to confirm the controls still hold.
- Confirm the retainer scope, response expectations and review cadence in the written agreement before work starts.
