Why penetration testing a Kafka deployment needs its own scope
A penetration test of Kafka covers every route into the cluster and every control meant to stop misuse of it, and it is worth commissioning when a cluster carries regulated or business-critical data and its hardening has only been checked on paper. Kafka security is optional, so a cluster can run with unsecured listeners, mixed secured and unsecured listeners, or authentication on some paths but not others. The test has to start by establishing what is actually exposed, then work through each layer that the cluster depends on, rather than assuming the broker configuration reflects the running system.
The layers are separate attack surfaces. Listeners and their security protocols decide whether a plaintext port is reachable from networks that should never see it. SASL or SSL decides who can authenticate, and the documented SASL mechanisms (GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER) each fail in different ways. Authorization is handled by the StandardAuthorizer, which stores ACLs in the cluster metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so the tester must confirm that setting and the super user list directly. Connect, JMX, Schema Registry and web UIs often sit beside the cluster with their own authentication, and a weakness there can bypass every broker control. Each of these needs its own test objectives and its own evidence.
Scope the engagement in writing before work starts. Ask the provider to list every listener, management interface, Connect REST endpoint, JMX port and UI in scope, and to confirm which environment is tested. A production-like cluster with the same configuration and network paths gives useful results without the risk of disrupting live data. Confirm with your own team which Kafka release is running and which controls the Kafka security overview and the authorization documentation describe for it, because the tester will check the running behavior against those documents.
Which Kafka attack surfaces a test should cover
A Kafka test is only as complete as its scope. The six components below are where a self-hosted cluster usually exposes access paths beyond the brokers themselves, and each one should be listed explicitly in the statement of work with its owner and test accounts.
Broker listeners and plaintext ports
Each listener defines a name, port and security protocol, and a broker can run plaintext and secured listeners side by side. The tester should enumerate every listener on every broker, including the controller listener, and confirm which ones accept unauthenticated connections and unencrypted traffic. A plaintext listener left open on a routable network lets anyone on that path produce, consume and read metadata without credentials. Ask the platform team for the full listener map from the broker configuration before testing starts.
SASL and TLS authentication paths
Kafka accepts SSL and several SASL mechanisms, including GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. Each mechanism is a separate path into the cluster, so a test should attempt authentication through every enabled one, check whether client certificate verification is required or merely requested, and try weak or default credentials. A weakness here allows a client to reach the cluster as an arbitrary or privileged principal. Confirm with the team which mechanisms are enabled on which listener, since a mechanism enabled on one listener can still be reachable from another.
ACL enforcement and default-deny behavior
In KRaft clusters the StandardAuthorizer stores ACLs in the metadata log, and resources without a matching ACL are restricted to super users unless allow.everyone.if.no.acl.found is set to true. The tester should confirm that default-deny holds on new topics and consumer groups, check whether any principal holds wildcard or cluster-level permissions, and test whether an authenticated low-privilege client can read, write or alter topics outside its prefix. Also check the super users list, since any entry there bypasses the ACL model entirely.
Kafka Connect REST API
The Connect REST API lets authorized callers create and modify connectors, and connector configuration can reference plugin classes and overrides. The tester should check who can reach the REST port, whether the API is protected by authentication, and whether the connector override policy restricts client configuration. A weakness can let an attacker create a connector that runs attacker-chosen code on workers or redirects data to an external sink. Confirm which plugins are installed on the workers and who may upload them, because each installed plugin widens what a malicious configuration can do.
JMX and metrics endpoints
Remote JMX on brokers and Connect workers exposes management operations as well as metrics, so an unauthenticated JMX port can allow reconfiguration or disruption of the process. The tester should scan for open JMX and exporter ports from the networks that should not reach them, verify whether JMX requires authentication and TLS, and check whether metrics exporters bind to all interfaces. Confirm with the operations team which monitoring systems legitimately scrape these endpoints, so that any reachable port outside that list is recorded as a finding.
Schema Registry and web UIs
Schema Registry, Kafka UI tools and similar dashboards often sit beside the cluster with their own authentication, service accounts and admin functions. The tester should check whether registry endpoints allow schema registration or deletion without the expected identity, whether UIs store Kafka credentials in readable configuration, and whether admin consoles expose topic creation, ACL editing or consumer offset resets to ordinary users. Because these tools hold broker credentials, a weakness in one can give an attacker the same access as the cluster client it represents. Ask for the list of every such tool, its version and the service account it uses.
Scoping a Kafka test: what to define before testing starts
The most useful thing a written scope can do is name the exact Kafka version under test. The Kafka downloads page lists 4.3.1, 4.2.2 and 4.1.2 as the supported releases, so those are the versions a current assessment should expect to find. If the client runs a release outside that list, or a 3.x or 4.0 cluster still on an older upgrade path, flag it in the scope document before testing starts, because findings on an unsupported release may not map to a fix the client can actually apply. Ask the client to confirm the broker version, the client library versions for each application, and whether the cluster runs in KRaft mode, since the metadata and authorizer behavior you test depends on it. Record the version of Kafka Connect, Schema Registry and any UI as well, since those are often older than the brokers they front.
Define which environments are in bounds. A production-like cluster with the same listener layout, authorizer settings, topic naming and ACL set is usually the right target, because it lets you test authentication bypass and ACL gaps without touching customer data or live consumer groups. If the client wants a test against production itself, the written scope should say which read and write operations are permitted, which topics are off limits, and who on the client side can stop the test. Name every listener and network path in bounds: each listeners and advertised.listeners entry, the controller listener, any external load balancer, the Connect REST port, the JMX port, and the Schema Registry and UI hostnames. Ask for a list of plaintext ports explicitly, because a broker can run unsecured and secured listeners side by side, and that mix is where many exposure findings come from.
Decide whether the test is white-box or black-box, and write that choice into the scope. A white-box test with exports of server.properties, the authorizer configuration, the output of ACL listings and the Connect worker configuration lets you check the intended design against the running cluster, and it shortens the time spent on discovery. A black-box test starts from network access and tests what an outsider or a low-privileged tenant can reach. Either way, agree on test accounts in advance: how many principals, which roles they hold, whether they are SCRAM, certificate or Kerberos identities, and how credentials are delivered and revoked at the end. Confirm whether allow.everyone.if.no.acl.found is set, since the answer changes what an unauthenticated or unlisted principal can do and should be verified rather than assumed.
Test approaches and when each fits
This table compares four ways to scope a Kafka security test: external black-box, grey-box with a client credential, white-box configuration review, and an internal assumed-breach scenario. Read each row for what the approach proves, what the client must supply, and where it can disrupt the cluster, then match the approach to the question the test must answer.
| Approach | What it proves | What it needs from the client | Main risk to the cluster |
|---|---|---|---|
| Black-box external | Whether broker, Schema Registry or Connect ports are reachable from outside the intended network and what they reveal before login | Written scope, source address ranges, a named contact for pausing tests, and confirmation of which hostnames are in scope | Probing unauthenticated listeners can trigger broker log noise, connection exhaustion or alerts on shared edge devices |
| Grey-box with a client credential | Whether a low-privilege SCRAM, Kerberos or mTLS identity can read or write topics it should not reach, and where ACLs have gaps | A test principal with narrowly chosen rights, test topics, and agreed limits on produce volume and consumer group names | Test produce or consumer group activity can affect real consumers, offsets or retention if test topics overlap production data |
| White-box configuration review | Whether broker, Connect and ACL settings match the intended design, including plaintext listeners, allow.everyone.if.no.acl.found and open Connect override policies | Read access to server.properties equivalents, ACL listings, Connect worker configuration and deployment manifests, with no need for live write access | Low operational risk, but configuration exports can expose secrets, so they must be stored and handled under the client's data controls |
| Internal assumed-breach | How far an attacker already inside the network could move, including reaching JMX, Connect REST and inter-broker ports | Network access from an agreed internal segment, rules of engagement, and a decision on whether lateral movement beyond Kafka is in scope | Highest impact: exploitation of administrative endpoints could change topics, connectors or broker state, so it should run on production-like clusters first |
How a Kafka penetration test runs, step by step
The sequence moves from written authority and a safe-testing agreement through configuration review and low-impact probing to a report and a retest, so each finding is confirmed against the cluster as it is configured. Every step closes with a check that must pass before the next one starts.
Agree rules of engagement and safe-testing terms
The client and the tester sign a written rules of engagement document that names the clusters, brokers, Connect workers, Schema Registry instances and UIs in scope, the source addresses the testers will use, the test windows, and the people to call if a broker degrades. A separate safe-testing agreement lists which actions are forbidden, such as topic deletion, partition reassignment, ACL changes and fuzzing of production producers. The step is done when both parties have signed and the escalation contacts have been confirmed by phone or another channel outside the cluster under test.
Confirm environment, backups and rollback path
The client confirms which environment is being tested, whether it is production, a production-like copy or a staging cluster, and that it matches the production configuration closely enough to support the findings. The client's operations team confirms a recent backup of the metadata and the data that the test could touch, and the tester writes down how to restore a topic, an ACL set or a broker configuration. Any write test is blocked until a rollback path has been rehearsed on a non-production cluster. The step closes when the client signs off on the environment and the rollback owner is named.
Export and review configuration and ACLs
Before sending any traffic, the tester reviews the broker, controller and Connect configuration files, the listener and security protocol maps, the authorizer settings, and the ACL and user credential lists as exported by the operator. The review checks whether the authorizer is set to deny by default, whether allow.everyone.if.no.acl.found is enabled, which principals are super users, and which ACLs grant wildcard resources or broad operations. Findings from the paper review become the test plan. The step is complete when the tester and client agree on the list of hypotheses to verify live.
Discover listeners and exposed ports
The tester maps which addresses and ports answer on each broker, controller, Connect worker, Schema Registry and UI host, using scans limited to the agreed address ranges and rate settings. The aim is to find plaintext listeners that the configuration review said were closed, listeners reachable from networks that should not reach them, and management ports that should not be open at all. Each open port is matched to a documented listener or service. The step is done when every discovered endpoint is either matched to the approved design or logged as an exposure for follow-up.
Test authentication and authorization with low-impact probes
The tester attempts connections with no credentials, with invalid credentials, with a mechanism that the listener should not accept, and with a valid low-privilege identity to check what that identity can read, produce and describe. Probes use metadata requests and read-only operations first, and any produce test uses a dedicated test topic that the client created for the engagement. The tester records which ACLs allow access that the design did not intend. The step closes when each hypothesis from the configuration review has been confirmed, disproved or marked as untestable without a write, with the evidence captured.
Test Connect, JMX, Schema Registry and UIs
The tester checks whether the Connect REST API accepts requests from unapproved hosts or without authentication, whether connector configuration overrides can change worker behavior, and whether the worker principal has broader rights than needed. JMX endpoints are checked for remote access without authentication and for exposure outside the monitoring network. Schema Registry and any Kafka UI are tested for authentication, role separation and whether they can change topics or schemas. Connector creation and schema registration are tested only on the dedicated test resources, and the tester removes them afterward. The step is done when each component has a recorded result and any cleanup is confirmed by the client.
Report findings and retest after fixes
The tester delivers a report that lists each confirmed finding with its evidence, affected component, the observed behavior, the impact on the data flowing through the cluster, and a recommended fix that the client can implement in its own configuration. Findings that could not be confirmed are listed separately with the reason. After the client applies fixes, the tester repeats the relevant probes on the same environment and records whether each finding is closed, partly closed or still open. The step is complete when the client accepts the retest results and the test artifacts are handed over or deleted as agreed.
Running tests safely against production-like clusters
Testing a production-like Kafka cluster is only safe if the test plan protects consumers and data before the first probe is sent. Use dedicated test topics, dedicated test principals and a documented allow-list of brokers and listeners that the tester may touch. Keep write probes off any topic that a production producer or consumer group uses, and cap message rates and payload sizes so a test cannot fill a disk, saturate a partition leader or push consumer lag past what your on-call team can see. Agree the time window with the owners of each topic and the Connect cluster in writing, and name a stop condition that anyone on the bridge call can invoke. Confirm with your platform team which quotas and producer limits apply to the test principals, because a test that passes on a quota-free lab can behave differently once quotas are enforced.
Production-like does not mean production with the brakes off. It means the same configuration: the same listener map, the same sasl.enabled.mechanisms and authorizer.class.name, the same TLS trust chain, the same allow.everyone.if.no.acl.found setting, the same Connect worker configuration and the same MirrorMaker 2 links if they exist. A simplified lab that enables a plaintext listener or runs without ACLs will tell you little about the controls you are paying to verify. Ask the platform owner to export the effective broker and Connect configuration and compare it with the test environment before the engagement starts, and record every difference as a finding about the test itself.
Plan the cleanup as part of the test, not after it. Record every topic, ACL, SCRAM credential, delegation token, client certificate and Connect connector the test creates, with its owner and creation time. Remove test ACLs and principals as the last step of each phase, check that no connector or plugin the tester uploaded remains running, and confirm that test topics are deleted or set to a short retention period. Keep monitoring dashboards and alerts on during the whole window, and watch for unexpected consumer lag, broker request latency and disk growth so that any side effect is caught while the test is still running.
Risks a Kafka test must check for and how they show up
A Kafka penetration test looks for a small set of recurring weaknesses, and each one leaves a different trace in the cluster, its configuration and its surrounding tools. The cards below describe what each risk is, how a tester can check for it in general terms, and what precautions keep the check from disturbing a running cluster.
Plaintext listeners left open
Kafka security is optional, so a cluster can run unsecured or mix secured and unsecured listeners. A test should map every advertised listener, confirm which ones accept connections without TLS or SASL, and check whether inter-broker traffic travels in clear text on the same network. Confirm the listener list with the cluster owner before probing, and use read-only metadata requests rather than produce or consume calls against production topics. Record each open port with its network source so the fix can be assigned to a specific firewall or listener change.
Weak or shared SASL credentials
SCRAM and PLAIN credentials are only as strong as their passwords and how widely they are shared. Testers should check whether SCRAM users have distinct, rotated credentials, whether one account serves several applications, and whether PLAIN is enabled without TLS, where credentials cross the network in a form that can be read. Password policy and secret storage are usually outside Kafka, so review where clients keep their credentials. Test guessing only against a dedicated test account agreed in the scope, with lockout and alerting behavior confirmed beforehand.
ACL gaps that fall back to super users
In KRaft clusters the StandardAuthorizer stores ACLs in the metadata log. Resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so that setting is the first thing to read. Testers should list the ACLs for sensitive topics, groups and cluster resources, then compare them with the principals actually connecting. Look for wildcard principals, overly broad prefixed ACLs and super users used by applications. Verify access by attempting an operation with a low-privilege test principal, and keep the operation read-only or confined to disposable test topics.
Connect REST access allowing connector overrides
The Kafka Connect REST API lets an operator create and modify connectors, and certain connector configuration overrides can point the worker at code or settings the operator did not intend. A test should confirm which network segments can reach the REST port, whether it requires authentication, and which client config override policy is in effect. Review the list of installed plugins for anything unexpected. Enumerate endpoints with GET requests only, and do not create or alter connectors on a shared worker without written approval and a rollback plan.
JMX exposed without authentication
Remote JMX gives management access to a broker or Connect worker, and an unauthenticated port can expose metrics, configuration and in some cases operations that change runtime state. Testers should check whether JMX ports listen on interfaces beyond the monitoring network, whether authentication and TLS are enabled, and whether an exporter could serve the same data from a restricted port instead. Confirm the port inventory before scanning, and limit checks to connecting and reading attributes. Avoid invoking management operations, since they can restart components or change behavior.
Schema Registry and UIs with weak access
Schema Registry, web consoles and topic browsers often sit beside the cluster with their own login, and they may hold credentials that reach every topic. A test should confirm whether these tools require authentication, whether their service accounts have broader Kafka permissions than the users who sign in, and whether they reveal message samples or schemas to unauthenticated visitors. Review the tool's own admin pages and API paths, and note whether it stores broker credentials in a readable file. Coordinate read-only checks with the owners, since some UIs read message payloads during browsing.
Questions buyers ask before testing Kafka
What drives the cost and effort of a Kafka penetration test?
The number of listeners, authentication mechanisms and access paths in scope drives effort most. A test of one plaintext listener and one SASL listener takes less work than a test covering brokers, the Connect REST API, JMX, Schema Registry and several web UIs, each with its own roles. Cluster size matters less than the number of distinct trust boundaries. Cost has two parts: the tester's time for planning, testing and reporting, and the client's time for access, configuration exports and review of findings. Ask any quote to list the components in scope, the environments covered, whether retesting is included and which activities, such as load-sensitive tests, need a maintenance window.
How long does a scoped Kafka penetration test take?
Duration depends on scope and must be agreed in writing before work starts. Planning covers rules of engagement, test accounts, safe testing windows and contacts. Testing covers the in-scope listeners, authorization checks and management interfaces. Reporting covers evidence, severity and remediation advice. Each phase can run longer when access is delayed, when a finding needs confirmation in a non-production copy, or when the client's cluster behaves unexpectedly under test. Ask for a timeline that names each phase, its dependencies on your team, and the date the written scope will be signed.
What must our team provide before a Kafka test starts?
The test team needs access and information it cannot infer from the outside:
- Network access to the in-scope bootstrap addresses, Connect workers, Schema Registry and UIs, from an agreed source network
- Configuration exports, such as the broker
server.propertiesfiles, listener maps, and the ACL list from the cluster - Test accounts with the roles real users hold, including a low-privilege account for each team and an agreed owner for any credentials created
- Named contacts for technical questions, incident response and emergency stop decisions
Also confirm which systems are out of bounds, such as shared tenants or downstream consumers you do not control. Keep credentials in a secrets store and agree how they are rotated or revoked at the end of the test.
Can our own security team run a Kafka penetration test internally?
Yes. An internal team can test the same surface, provided it works to the same written scope and safety rules: agreed targets, test windows, stop conditions, data handling and a named contact who can halt activity. Internal testers often know the cluster better, which helps with ACL and role analysis, but they may also share assumptions with the people who built it. Independent review of ACL design, unauthenticated paths and the Connect REST API is useful when those controls were configured by the same team that operates them. Decide up front who owns the findings and how they are tracked.
Should we run a Kafka penetration test against production?
Testing against a production-like cluster is usually the safer choice. Kafka handles live traffic for consumers, producers and downstream systems, and some checks, such as producing test messages, creating topics or changing ACLs, can affect them. A production-like environment should match listener configuration, authentication, ACLs and versions. Where production testing is necessary, limit it to read-only checks and agreed test topics, schedule it in a window, and have an owner ready to stop the test. Confirm with your change board and with the owners of connected systems before you agree to it.
What does retesting after fixes involve for Kafka?
Retesting checks that each finding is closed and that the fix did not open a new path. For Kafka this usually means re-running the specific checks against the changed listener, role, ACL or Connect setting, then confirming the result in the running configuration rather than in a change ticket. Fixes such as removing a plaintext listener or tightening a prefixed ACL can affect clients, so retesting should include a check that legitimate producers and consumers still work. Ask whether retesting is included in the quote, how many rounds it covers, and what evidence will be recorded for each closed finding.
How DeployOpen scopes and delivers Kafka security testing
DeployOpen runs security testing of applications, infrastructure and APIs, and a Kafka engagement follows the same discipline. The scope is agreed in writing before any work starts, and it names the exact clusters, listeners, Connect workers, Schema Registry instances, JMX endpoints and UIs in play. For Kafka, the scope should state which listeners are in bounds (for example, whether a plaintext port reachable from a build network may be probed), which test accounts DeployOpen will be given, whether tests may create or delete topics, and which hours are acceptable for load-generating checks. A quote follows from that written scope, so the more precisely the client defines it, the more precisely the work can be priced and timed.
Testing takes place inside your own infrastructure, in the cloud accounts, data centers or restricted networks you control, against a non-production cluster that matches production configuration wherever possible. Where a test would touch production data, the scope should describe how that data is masked or how the test is limited to synthetic topics. Findings are reported with remediation guidance tied to the specific setting, such as an ssl.client.auth value, an ACL rule or a allow.everyone.if.no.acl.found setting, so that your platform team can act on them directly. DeployOpen prepares that evidence and advice, but it does not issue audit reports, attestations or certifications. If you need an independent opinion for an assessment, that comes from an auditor or certification body, and the reader should confirm early which evidence that body expects.
Because Kafka configurations change with every release and with every new team onboarded, DeployOpen offers retainers for retesting after remediation and for continuous testing on a schedule you agree. Ask for the retest criteria in the quote: which findings must be closed, what evidence will be produced for each, and whether retests run against the same environment or a rebuilt one. Confirm also how Kafka's own release and fix cadence will be tracked during the retainer, since a retest is only meaningful against the version you actually run.
