Why Apache Kafka security hardening takes more than turning on TLS
Turning on TLS on the client listener is the step most teams finish first, and it is rarely the step that decides whether a Kafka cluster is ready for production or an audit. Kafka security is optional by default. A cluster can run with no encryption and no authentication, or it can mix secured and unsecured listeners, so a single broker that still exposes a plaintext port undoes the work done on every other listener. Hardening means closing every listener, every identity path and every administrative path, and then confirming that each one is closed in the running cluster rather than in the intended configuration.
Teams usually need this work at three points. The first is a new production cluster, where defaults set during early testing tend to carry forward. The second is a shared cluster, where several applications, teams or tenants publish and consume through the same brokers, so one permissive path exposes everyone's topics. The third is compliance readiness, where an assessor will ask how access is granted, how it is revoked and how changes are recorded. Each of these starts from the same question: which identities can reach which resources, and how would you know if that changed?
The difficulty is that the client listener is only one of several paths. Inter-broker traffic is configured separately through the inter-broker listener and must be encrypted and authenticated in its own right. Controller traffic in KRaft mode uses its own listener and its own security settings, so a cluster can look locked down from the client side while the controller quorum accepts connections it should not. Kafka Connect workers talk to brokers with their own credentials and expose a REST API that needs its own authentication and network restriction. Admin tools such as the command-line utilities for topics, configurations and ACLs connect with whatever credentials are passed to them, and those credentials are often stored in shell history, scripts or CI variables that nobody reviews.
Authorization needs the same discipline. In KRaft clusters, the StandardAuthorizer keeps ACLs in the cluster metadata log, and resources without a matching ACL are limited to super users unless allow.everyone.if.no.acl.found is set to true. Confirm that this setting is false or unset in every environment, and decide deliberately who holds super user rights, because that role bypasses ACL checks. Then test the policy: list the principals, the resources and the operations each one can perform, and compare that list with the access your owners approved. Audit logging of authorization decisions and administrative changes should be planned in the same pass, so the evidence exists before anyone asks for it.
Before scoping the work, ask your team or a partner to produce an inventory of every listener, controller and inter-broker endpoint, every principal and credential source, every admin and Connect path, and the current ACL set. That inventory defines what hardening must change and what a fixed-scope quote has to cover. Confirm the Kafka release you run and its supported status on the project's downloads page before you choose mechanisms, because some settings and authentication options depend on the version in use.
Which listeners, authenticators and authorizer settings you must configure
Kafka security is set across several components that each default to something different from a hardened setup. The cards below cover each one, what it controls and what happens if it stays at its default, so you can confirm every item before a cluster carries production data.
Client, inter-broker and controller listeners
Each listener is a network endpoint with its own security protocol, so a cluster can expose a plaintext listener alongside a secured one without anyone noticing. Client, inter-broker and controller listeners should each be reviewed separately, because the controller listener carries KRaft metadata traffic. Kafka security is optional, so an unreviewed listener may accept unencrypted connections. Confirm the listener and advertised listener property names against the Kafka 4.3 security documentation.
SSL and SASL authentication
SSL/TLS encrypts traffic and can establish client identity through certificates, while SASL authenticates clients, brokers and tools through a chosen mechanism. The documented SASL options are GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. Leaving authentication unset lets unidentified clients connect, so the mechanism choice must match your identity systems. Confirm the mechanism and keystore property names in the 4.3 security docs.
StandardAuthorizer and the metadata log
In KRaft clusters, StandardAuthorizer stores ACLs in the cluster metadata log, so access rules replicate with cluster metadata rather than living in a separate store. Kafka authorization is pluggable and can integrate with external authorization services, which matters if your policy lives outside Kafka. Without an authorizer configured, access control is not enforced. Confirm the authorizer class setting against the 4.3 authorization documentation.
Super users
Super users bypass ACL checks entirely, so every principal listed in the super user setting can read, write and change any resource. Keep this list short, limited to administrative identities, and review it whenever service accounts change. Treat the super user list as a privileged access inventory that auditors and your own security team should be able to see. Confirm the exact property name in the 4.3 authorization documentation.
Default-allow behavior for resources without ACLs
When no ACL matches a resource, Kafka restricts it to super users unless allow.everyone.if.no.acl.found is set to true. Enabling that setting turns unmatched resources into open access, which quietly undermines deny-by-default. Verify the value on every broker, because a single misconfigured broker changes the effective policy for the topics it hosts. Confirm the setting name and its scope in the 4.3 authorization docs.
Kafka Connect workers and REST API
Kafka Connect workers hold credentials for source and sink systems and expose a REST API for managing connectors, so the worker is an access point in its own right. Review worker security settings, the authentication used between workers and brokers, and who can reach the REST endpoint. Connectors that run with broad principals can bypass the intent of your topic ACLs. Confirm the worker and REST property names against the Kafka Connect documentation for 4.3.
Admin tools and client configuration
Command-line admin tools, such as those used for topic and ACL changes, connect to the cluster with their own security settings. Administrators who run these tools from workstations or jump hosts may hold credentials with wide permissions. Confirm which tools need a client configuration file, where those files are stored, and who can read them. Verify the tool configuration options in the 4.3 documentation before rolling out a shared admin profile.
Which authentication mechanism and authorization model to choose
This table compares the documented SASL mechanisms, SSL client authentication and the two authorization models Kafka offers, along with the operational work each one adds. Read each row for its fit and recurring effort, then check the last two rows, which set the deny-by-default position and limit super users. Identity provider configuration is covered in the Apache Kafka SSO and identity integration topic.
| Option | When it fits | Operational cost | Watch for |
|---|---|---|---|
| GSSAPI (Kerberos) | Organizations with an existing Kerberos realm or Active Directory | Keytab distribution, ticket lifetimes, KDC availability and clock synchronization | Principal names must match ACLs exactly; confirm how keytab rotation will be automated |
| PLAIN | Small internal clusters or short-lived test environments | Passwords kept in client configuration, so rotation reaches every client | Only use with TLS on the listener, since credentials are sent on each connection |
| SCRAM-SHA-256 or SCRAM-SHA-512 | Teams that want Kafka-managed credentials without running a directory | Credentials stored in cluster metadata, rotated through admin tooling and vaulted by clients | Choose one mechanism per cluster and confirm client library support before rollout |
| OAUTHBEARER | Organizations standardizing on an OIDC identity provider for users and services | Token validation settings, identity provider endpoint availability and client token refresh | Depends on the identity provider; setup details sit in the SSO topic |
| SSL client authentication (mutual TLS) | Service-to-service links where a private certificate authority already issues certificates | Issuance, renewal, revocation and distribution of certificates to every client and broker | Expired certificates cause outages, so monitor expiry dates from day one |
| StandardAuthorizer (built-in) | Clusters that want ACLs enforced by Kafka with no extra service to operate | ACLs stored in the cluster metadata log, managed through scripts or pipelines and change review | Confirm an ACL-as-code workflow before go-live so changes are reviewed and reproducible |
| External authorization service | Organizations that must govern Kafka access through central policy tooling | A plugin or integration to build, test and upgrade with each Kafka release | Adds a dependency on the policy service; plugin packaging is covered in the customization topic |
| allow.everyone.if.no.acl.found | Keep false in production; set true only for a documented migration window | When true, resources without an ACL become open to every authenticated client | Add explicit ACLs for every resource before go-live and record any temporary exception |
| Super users | Break-glass administrator accounts and platform service accounts only | Super users bypass ACLs, so each account needs vaulting, audit logging and periodic review | Keep the list short, record every entry in change control and alert on its use |
How to harden a Kafka cluster in the right order
This sequence takes a Kafka cluster from unsecured listeners to encrypted, authenticated and authorized access, with a check at each step that proves the step is closed before the next one changes what clients depend on.
Inventory every listener and client path
Before changing anything, list each listener on every broker and controller, the protocol and port it uses, and every client, Connect worker, tool and replication path that connects to it. Include applications, scheduled jobs, monitoring agents and any MirrorMaker 2 flows. The output is a reviewed table mapping each path to its listener, its current authentication (often none) and its owner. This table is the baseline that every later step checks against, so a path missing from it is a likely outage later.
Issue and distribute TLS certificates on all listeners
Create a certificate authority or connect to your existing internal one, then issue broker and controller certificates with the correct subject alternative names. Cover inter-broker and controller traffic as well as client listeners, because Kafka's security is optional per listener and an unencrypted internal listener remains exposed. Distribute truststores and keystores through your secrets process, and keep the old unsecured listener running until clients are moved. Close this step when a test client completes a TLS handshake against each new listener using the expected certificate chain.
Configure SASL on the chosen listeners
Select the SASL mechanism for each client group from the documented options: GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 or OAUTHBEARER. Enable SASL on the secured listeners only, and keep the plain listener until all clients are migrated. Credentials for SCRAM must be created before clients switch. Close this step when a client authenticates over the secured listener with valid credentials, and an attempt with a wrong password or no credentials is refused by the broker with an authentication error.
Set the authorizer with deny-by-default
Configure the StandardAuthorizer for the KRaft cluster and keep allow.everyone.if.no.acl.found set to false. In KRaft clusters ACLs live in the metadata log, and resources without ACLs are then limited to super users, so applications without a grant will fail rather than succeed silently. Check this before cutover: a client that still reaches the cluster on the unsecured listener must be expected to fail once its listener is closed. Close this step when an authenticated principal without an ACL is denied a produce or consume request on a test topic.
Define super users narrowly
Limit super.users to a small set of named broker and operator principals, and record who holds each one. Super users bypass ACL checks, so every additional entry widens what a single credential can do. Do not place application principals in this list to avoid writing grants. Close this step when the configured list matches the reviewed roster and a non-super principal without grants cannot alter topics, ACLs or configurations.
Grant ACLs per principal, topic and group
Build ACLs from the reviewed inventory in step one, granting each principal the operations it needs on named topics, consumer groups and transactional IDs. Use literal names where possible and prefixed patterns only with agreement from the owning team. Apply grants in a staging cluster first, then in production in the order of the client migrations. Close this step when each application completes its normal produce and consume workload, and a sample of out-of-scope topic access is denied in the audit results.
Secure Connect workers, REST access and admin tools
Apply the same TLS and SASL settings to Kafka Connect workers and their internal topics, secure the Connect REST API with authentication and TLS, and restrict who can run administrative tools such as topic, ACL and configuration commands to operators on controlled hosts. Confirm the replication flows still authenticate after changes. Close this step when a worker restarts and reconnects over the secured listener, an unauthenticated REST request is refused, and an admin command from an unapproved host fails.
Hardening Connect, admin tools and credentials without locking out operators
Broker hardening only protects part of a Kafka estate. Connect workers, the REST API, command-line tools and the credentials behind them need their own identities, controls and recovery paths. The cards below cover each of these areas and the break-glass access that keeps operators working when a control fails.
Separate operator, application and connector identities
Give humans, applications and connectors distinct principals so each can be granted only the ACLs its job requires. Shared accounts make audit logs useless and force broad grants that outlive the people who needed them. Before enabling authorization, list every principal that touches the cluster, the topics it reads or writes and the group it belongs to. Check that no application reuses an operator account.
Authenticate and authorize Connect workers
Connect workers talk to the brokers as clients, and distributed mode stores its configuration, offsets and status in internal topics. Each worker needs an authenticated principal with ACLs limited to those internal topics and to the topics its connectors use. Connector principals should be separate from the worker principal so a misconfigured connector cannot change worker state. Confirm the exact ACL set against the Kafka authorization documentation for your version.
Secure the Connect REST API
The Connect REST API can create, pause, reconfigure and delete connectors, so an open endpoint is effectively administrative access to the data pipeline. Restrict it to TLS, bind it to management networks where possible and require authentication in front of it. Decide which teams may change connector configuration and which may only read status. Connector configuration often holds database passwords, so check how those values are stored and whether they appear in API responses.
Restrict command-line admin tools to named operators
Tools such as topic, ACL and configuration utilities connect with their own client configuration, which is often copied between hosts and forgotten. Issue each operator a named principal, give the admin tools client properties only on approved jump hosts, and log which principal ran each change. Review the super user list and remove any shared or default account. Test that a standard operator can perform routine topic work without holding cluster-wide admin rights.
Handle SCRAM credentials, keystores and truststores as secrets
SCRAM user credentials, TLS keystores and truststores and their passwords are secrets, and they usually end up in configuration files, container images or CI variables. Store them in a managed secret store, restrict read access to the service accounts that need them and set a rotation procedure before go-live. Record the expiry date of every certificate. Verify that rotation does not require a full cluster restart, and test it in a non-production environment first.
Document and test break-glass super user access
Super users bypass ACLs, so a controlled break-glass account is needed for incidents, such as a broken authorizer or a lost certificate authority. Keep its credentials sealed in a separate vault, require two named approvers to release them and alert on every use. Write the recovery steps down and rehearse them on a staging cluster, including a rollback of an ACL change. Revisit the procedure whenever the principal list or authorizer configuration changes.
How to produce audit evidence from Kafka authorization and admin activity
An audit trail for Kafka should answer four questions for any point in time: who connected, which principal performed which operation on which resource, which requests were denied, and who changed ACLs, users or broker configuration. Each question maps to a different source. Connection and authentication events come from the brokers' listeners, authorization decisions come from the authorizer, and administrative changes come from the tools and APIs that write to the cluster metadata. Start by writing these four questions into your control design, because they determine which log categories you must enable and which fields every record needs, including the authenticated principal, client address, operation, resource type and name, and timestamp.
Authorization denials are the most useful starting point. In a deny-by-default design with StandardAuthorizer, every rejected request is a signal that a client lacks an ACL or is misconfigured, and that record is evidence that the control worked. Enable authorizer logging at the level your version documents for denials, and confirm the logger name and the fields it writes in your release before you build parsers. Admin actions need a separate path. Changes to ACLs, SCRAM credentials and topic or broker configuration should be traced to an authenticated principal. Because ACLs in KRaft clusters live in the cluster metadata log, confirm how your version exposes changes from that log, and whether you can export them on a schedule to the same store as broker logs.
Shipping logs to a central store is the easy part to build and the easy part to forget to test. Use a log shipper on every broker, controller and Connect worker to forward files to a store you control, and keep the original file as the record of truth. Preserve the time source by confirming NTP synchronization on every host, since audit timelines fail when clocks drift. Record the Connect REST API and command-line admin tools too, because their actions may appear in different logs from broker activity. Plan a test in which you create a test principal, deny a request, change an ACL and rotate a credential, then confirm that each event appears in the central store with all required fields. Keep the test script as evidence that the pipeline works.
Several gaps need to be confirmed in the target version rather than assumed. Check whether successful operations are logged with the same detail as denials, whether all admin operations generate an event that identifies the actor, whether log4j configuration changes are themselves recorded, and whether the logs contain enough context to tie a denial to the client application. Do not treat the absence of a log line as proof that an action did not happen until you have tested it. Before you design retention periods, confirm which Kafka logs and events your version emits and what each contains. DeployOpen prepares controls, configuration and evidence for compliance assessments, but independent auditors decide whether those controls meet the applicable criteria and issue any opinion or attestation.
What drives hardening effort and how to keep it down
This table lists the factors that change how much work a Kafka hardening engagement involves, along with the levers that reduce each one. Read it as a checklist for scoping: the largest driver is usually the inventory of existing clients, so start there before comparing options. Ask any partner for a fixed-scope quote built from that inventory rather than from a general estimate.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Listeners and client applications | Each listener needs its own TLS and SASL settings, and each client application must be updated, tested and cut over to the secured endpoint. | Consolidate listeners by purpose (inter-broker, client, controller) and migrate clients in waves by team. |
| Teams and principals needing ACLs | Every principal needs ACLs written and reviewed, and each new topic or consumer group adds rules to maintain under deny-by-default. | Use prefixed ACLs and consistent naming, and grant access through reviewed templates per team. |
| Connect workers and connectors | Each worker needs secured REST and internal settings, and each connector needs credentials, secrets handling and its own ACLs. | Standardize on a small set of connectors and a shared secrets mechanism, and secure the REST API once for all workers. |
| External identity or authorization service | Integrating OAUTHBEARER, Kerberos or an external authorizer means identity provider configuration, claim mapping and failure-mode testing. | Pick one identity source early, confirm the mechanism your clients support, and limit custom authorizer plugins. |
| Certificate authority arrangements | Existing PKI rules, certificate lifetimes, hostname conventions and renewal processes determine how much certificate work is needed. | Confirm the CA, issuance workflow and renewal owner before design, and reuse existing internal CA profiles where possible. |
| Environments (dev, test, production, air-gapped) | Each environment needs its own certificates, credentials and ACL sets, and air-gapped networks add offline package and artifact handling. | Automate configuration per environment from one template, and plan offline artifact transfer once rather than per environment. |
| Compliance evidence requirements | Assessors may ask for configuration evidence, access reviews, audit log retention and change records for each control. | Agree the evidence list before work starts, and keep configuration in version control so evidence is generated from the same source. |
| Client inventory (largest single driver) | Unknown clients, undocumented topics and shared credentials usually surface during rollout and extend testing and cutover. | Inventory every client, topic and credential before scoping, and request a fixed-scope quote based on that written inventory. |
What to monitor, rotate, review and document after hardening
Hardening only holds if someone watches it. Start with two signals that show the controls are working: authentication failures on each listener and authorization denials from the StandardAuthorizer. Failed SASL logins and TLS handshake errors usually point to broken client configuration, expired credentials or unwanted probing. A steady stream of denials usually means an application lacks a grant it needs or a team is reaching for topics it should not. Route broker logs and authorizer logs to your central logging system, and confirm which JMX metrics and log categories your chosen release exposes for these events, since names can change between releases. Alert on sustained increases, and review the individual denials with the owning team each month.
Certificates and SCRAM credentials expire on dates that rarely coincide with staffing. Build a register that lists every broker, controller, Connect worker and client keystore, with its issuing authority, subject and expiry date, and set reminders well ahead of each one. Plan certificate rotation as an overlap: issue the new certificate, trust it alongside the old one, reload or restart listeners in a planned order, then retire the old certificate. For SCRAM-SHA-256 and SCRAM-SHA-512 users, create the replacement credential before deleting the old one so applications can switch without an outage. Test both paths in staging, and ask your platform team to confirm how dynamic listener and credential changes behave in your Kafka release before relying on them in production.
Access rules drift over time. Schedule a review of ACLs at a fixed interval, comparing each principal and resource pair against a named owner and a documented purpose. Remove grants for decommissioned applications and for service accounts nobody can explain. Review the super.users list with the same care, because super users are not limited by ACLs. Keep that list short, tie each entry to a named person or service, and record every change. Confirm that allow.everyone.if.no.acl.found is still set to false, since a change to that setting would open resources that have no ACL. Export ACL state before and after each review so changes can be audited, and treat any grant the owner cannot confirm as an open finding.
Keep the cluster on a release that still receives bugfixes. The Kafka downloads page lists 4.1.2, 4.2.2 and 4.3.1 as supported releases, and earlier versions are archived. The project aims for three releases a year, so agree in advance how quickly your organization will schedule a move after a new release. Rolling upgrades are supported from each of the last three releases to the latest version, so a cluster that falls outside that window will need a staged path. Test every upgrade in a staging cluster that matches production in version, security configuration, client mix and ACL content. Run your hardening checks there before booking the production change window, and keep the test record with the change ticket.
Security settings must be verified again after every upgrade. Defaults can change between releases, and plugins such as a custom authorizer or authentication provider may behave differently against a new broker version or fail to load. After each upgrade, rerun checks for listener TLS, SASL mechanisms, deny-by-default authorization, super user membership and Connect REST API access, and confirm that audit logs still record authentication and authorization events. The handover should include the architecture and listener map, a configuration baseline for each component, the certificate and credential register with its rotation runbook, the ACL and super user inventory with named owners, monitoring and alert definitions, the upgrade and rollback procedure with staging test records, and incident contacts. Ask for each document to carry a version and date so the next team can see what was true when it was written.
What buyers ask before hiring help with Kafka hardening
How much does Apache Kafka security hardening cost?
The cost depends on the written scope: how many clusters, listeners, client applications, Connect workers and admin tools need changes, and which identity systems must be integrated. Kafka is licensed under Apache-2.0 with no license fee, so the quote covers people and environment work. Most of the cost is one-time: assessing the current state, designing TLS and authentication, changing clients and connectors, modeling ACLs, verifying each change, and writing documentation. Recurring costs include certificate rotation, onboarding new principals and any ongoing support retainer you choose. DeployOpen works on fixed-scope engagements, and a fixed-scope quote follows from the written scope. Ask for line items per cluster and per client group, and confirm whether rotation and handover are included.
How long does Kafka hardening take to complete?
The duration depends on your inventory and environments, so no fixed timeline applies before the scope is written. The main variables are the number of clusters, the environments (development, test and production), how many client applications and teams must coordinate changes, how many Kafka Connect deployments exist, and whether your identity provider is ready to issue credentials. Change windows also set the pace, because listener changes on production brokers usually happen in steps. A typical sequence is inventory, then non-production validation, then production cutovers listener by listener. Ask for a schedule that ties each phase to the written scope and names the decisions your team must make at each stage.
What does my team need to provide for Kafka hardening?
Hardening depends on access and decisions from your side. You need access to client owners and their applications, so every producer, consumer and connector can be inventoried and updated. You need a certificate authority, or a decision on which one to use, plus a plan for issuing and rotating broker and client certificates. Identity systems must be available: an OIDC provider for OAUTHBEARER, a Kerberos key distribution center for GSSAPI, or a process for managing SCRAM credentials. You also need change windows for production brokers and a named owner who approves ACL decisions. Ask the engagement to list these inputs in writing before work starts, with a date by which each is needed.
Can an internal team harden Kafka without outside help?
Yes. Kafka's security features are documented and open source, so an experienced internal team can apply them. What makes the work succeed is verification and documentation. Test every listener with TLS and a SASL client, and confirm that unauthorized principals are refused when deny-by-default applies. Check that admin tools and Kafka Connect REST endpoints use the same protections. Confirm that audit logs capture authentication and authorization events. Record the configuration, the ACL model, the certificate rotation steps and the rollback plan. Gaps usually appear in two places: an incomplete inventory of clients and connectors, and ACLs that were copied from an older, more permissive setup without review.
Does hardening Kafka make the cluster compliant?
No. Hardening prepares controls and evidence, such as TLS settings, authentication configuration, ACL records, access logs and documented procedures. Compliance is assessed by independent auditors or certification bodies, who decide whether controls meet a given framework. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Before the work starts, ask your auditor which evidence they expect, which control areas apply to your Kafka environment, and how long they need to review the records. Then map each piece of evidence to the relevant control in your own terms.
Should Kafka be upgraded before or after hardening?
It depends on the version you run today. According to the Kafka upgrade notes, Apache Kafka 4.0 supports only KRaft mode, so ZooKeeper-based clusters must migrate to KRaft before upgrading to 4.x. The same notes recommend that KRaft clusters older than 3.3.x upgrade to 3.9.x before moving to 4.x. Rolling upgrades are supported from each of the last three releases to the latest version. Plan hardening and upgrades together where possible, so listeners and authentication change only once. Test the combined change in a non-production environment first, and confirm the target release on the Kafka downloads page before scheduling.
What changes with Kafka 4.x security defaults?
Kafka 4.x removes ZooKeeper mode, requires brokers, Kafka Connect and tools to run on Java 17, and requires clients and Kafka Streams applications to run on at least Java 11. On authorization, the StandardAuthorizer in KRaft clusters stores ACLs in the cluster metadata log. Resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Clusters that relied on open access under older configurations may therefore see clients refused after an upgrade. Review the upgrade notes for your target release, list every client that depends on open access, and confirm each default before the production rollout.
How DeployOpen scopes, hardens and hands over Kafka security work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Apache Kafka security. Kafka security work is agreed as a fixed-scope engagement with written deliverables, and ongoing support is available as a retainer.
How we scope
- Inventory every listener, client, broker, Connect worker and admin tool that must be secured before work starts.
- Confirm the Kafka release and KRaft mode, since the security approach depends on the version in use.
- Agree in writing which SASL mechanisms, ACL model and audit logging scope the engagement covers.
How we build
- Enable TLS on every listener, starting with inter-broker and controller traffic, then client listeners.
- Configure SASL authentication and StandardAuthorizer ACLs with a deny-by-default posture and tightly limited super users.
- Secure Kafka Connect, its REST API and admin tools, then test each control against negative cases before sign-off.
How we hand over
- Deliver configuration, certificate and credential procedures, ACL inventory and super user records as written documentation.
- Document audit logging settings, log locations and the review steps your team should run on a schedule.
- Walk your operators through rotation, onboarding of new principals and verification checks they will repeat.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer for security-hardened clusters.
- Plan security re-checks when moving to a new supported Kafka release, since configuration defaults can change.
- Confirm with DeployOpen during scoping which support terms, response expectations and testing cadence apply.
