Best tools for Kafka audit logging

The best tools for Kafka audit logging depend on which layer you need evidence from. At the broker, Kafka’s own kafka.authorizer.logger, Confluent Server audit logs, Apache Ranger’s audit and the managed-service logs from Amazon MSK and Google Cloud record authorization decisions. At the control plane, the audit logs in Kpow, AKHQ, Kafbat UI, Klaw and Conduktor record what people did through those tools. Data lineage, through OpenLineage-based tooling, answers where data went. Kpow is Factor House’s product, and I work at Factor House as a Solutions Architect, so it is scored on the same rubric and the same sources as every other option.

Apache Kafka ships no audit log as such. It ships an authorizer that can log its decisions, and everything else is built by tools around it. The Kafka security architecture guide covers audit alongside encryption, authentication and authorization as the four pillars. This page is about choosing the tools that produce audit evidence. For the wider governance picture, see Kafka stream governance and the complete Kafka guide.

What an audit logging tool has to do

A data platform engineer looking for Kafka audit tooling wants three things: tracking of who did what across the control and data plane, collection that does not load the brokers, and storage an auditor will accept. Those become the five criteria every option below is scored on.

1. Layer covered. Does the tool record broker authorization decisions, actions taken by people in a tool, or data movement? Each layer answers a different auditor question, and no single tool covers all three.

2. Reads as well as writes. A record of who deleted a topic is table stakes. Regulated teams also get asked who looked at a sensitive topic’s data. Sandy Yang, a staff engineer on TD’s Event Streaming Platform, described in her talk with us how TD grants data inspect access through a ServiceNow form, scoped for an hour or two, and said plainly: “This gives TD an audit trail.” A tool that logs mutations but not queries cannot produce that evidence.

3. The real identity. Does the record name the person, or a shared credential? When someone works through a Kafka UI, the broker sees the UI’s own principal. Tom Crowley, our founding engineer, explains this to customers asking how Kpow relates to ACLs: ACLs are “assigned to Kpow’s AdminClient connection”, while users are authorized by Kpow’s RBAC. The broker’s log will therefore show the tool’s service account for every action any user takes. Only the tool’s own audit log can say which person it was.

4. Overhead on the brokers. Audit that has to be switched on at DEBUG level on every broker is audit most teams switch off again. Collection that happens outside the broker request path costs the cluster nothing.

5. Retention and export. Can the trail be kept for as long as your regulator requires, and shipped to your SIEM or immutable storage? An audit log you can only browse in the tool for a week is a troubleshooting aid, not evidence.

There is a reason this matters in regulated environments that goes beyond access. Discussing retry topics with our team, I pointed out that on a SOC 2 audit, auditors “will want to ensure for example, that the data on the topic is exactly how the producing service intended it to be (i.e. no other person/process was able to put malicious data that could be used to hide financial crime etc)”. That makes the produce actions of people, not just their admin changes, part of what the audit log has to show.

Three layers of Kafka audit

Broker authorization. Every Kafka request passes the authorizer, and the authorizer can log each decision to kafka.authorizer.logger. In Apache Kafka’s StandardAuthorizer, denied requests are logged at INFO and allowed requests at DEBUG, and the default log4j2.yaml sets that logger to INFO, writing to kafka-authorizer.log:

- name: kafka.authorizer.logger
  level: INFO

So an out-of-the-box broker records denials only. Raising the level to DEBUG records allowed operations too, at the cost of a line per authorized request. The sources are the StandardAuthorizer code and the default log4j2 config.

Control plane. Tools that people use to change or read Kafka, such as UIs and self-service portals, keep their own audit logs. This is the layer that records the person, the request and its outcome in one place. The figure above sets it against the broker log. Tom made the case for this layer in 2021, writing about temporary access (now covered in break-glass access with temporary policies) about production fixes done the old way: a jump host that “generally has full access to the Kafka cluster, and there is no audit log recording the actions being committed.”

Data plane and lineage. Which producers wrote to a topic and which jobs consumed from it is lineage, not audit, but auditors increasingly ask for both. OpenLineage is the open standard here, a specification for events about datasets, jobs and runs. It tells you where data flowed, not who clicked what.

F1 What each layer can tell an auditor

Broker authorizer log Tool audit log (control plane)

Identity recorded The Kafka principal on the connection, often a shared service account The person, as asserted by your identity provider

What it captures Allow and deny decisions for every protocol request Each action taken in the tool, and in some tools each data query

Default output Denials only, at INFO, to kafka-authorizer.log Depends on the tool, from nothing to an audit topic and webhook

Blind spot Which human used the tool that held the credential Anything done outside the tool, such as a CLI on a jump host

Options by layer

Tools compared

Kafka audit logging options scored on the five criteria (read 22 September 2026)

Tool	Layer	Reads as well as writes	Real identity	Broker overhead	Retention and export	Source
Kafka authorizer log	Broker	Yes at DEBUG. Denials only at the default INFO	Connection principal only	Grows with request rate at DEBUG	Log files you ship yourself	Apache Kafka source
Confluent Server audit logs	Broker	Authorization decisions for protected actions	Principal	Runs in the broker	Kafka topics, then sink connectors	Confluent's documentation (not linked)
Apache Ranger	Broker	Access decisions	Principal	Runs in the broker plugin	Ranger's audit store	ranger.apache.org
Amazon MSK	Broker and API	Authorizer logs, API calls in CloudTrail	Principal or IAM identity	Managed by AWS	CloudWatch, S3, Firehose	AWS docs
Google Managed Kafka	Service API	Admin activity and data access logs	Google identity	Managed by Google	Cloud Logging	Google Cloud docs
Kpow	Control plane	Yes. Mutations always, data queries through the webhook's query setting	The user from your IdP, with the RBAC decision	None. Outside the broker path	Internal Kafka topic, webhooks to Slack, Teams or any endpoint. UI shows seven days	Kpow docs
AKHQ	Control plane	Writes only	The logged-in user	None	Kafka topic you nominate	AKHQ docs
Kafbat UI	Control plane	Writes by default, reads with level ALL	The logged-in user	None	Kafka topic or console	Kafbat docs
Klaw	Control plane	Requests and approvals	The requester and approver	None	Klaw's database	GitHub
Conduktor Console	Control plane	Console events	The logged-in user	None	UI and a Kafka topic in CloudEvents	Conduktor's documentation (not linked)
OpenLineage tooling	Lineage	Data flow, not access	Jobs and datasets	Depends on emitter	Lineage backend	openlineage.io

Read the table by column rather than by row. The identity column splits cleanly: broker-layer tools record principals and control-plane tools record people. A complete audit story takes one from each, alongside the permission models in Kafka RBAC tools, plus a rule that people do not hold broker credentials directly, so that everything they do passes through a tool that records it.

How Factor House approaches it

Kpow records every user action in an audit log retained in an internal Kafka topic, __oprtr_audit_log, and shows it in the UI. The audit log documentation shows what one record holds: the request itself, the user’s identity from the authentication provider, whether the user was authorized, the RBAC policies that were evaluated, and the action the request required. That last part is what lets an auditor see not just that a topic was created, but which policy allowed it.

For delivery, the webhook integration posts audit records as JSON to Slack, Microsoft Teams or any HTTP endpoint, which is how teams route them into a SIEM. Verbosity is set to mutations, queries or both, so data inspect queries can go to the same place as changes. Staged mutations and temporary policies, compared with other approval controls in Kafka destructive operations tools, land in the same log, so an approved break-glass grant and everything done under it sit in one trail. Jaehyeon Kim, on our team, walks through wiring this into Slack in real-time audit trail for Kafka via webhooks.

The trail needs no new infrastructure. It is a Kafka topic on a cluster you already run, inside your own network, so the audit data never leaves your environment on its way to your SIEM.

Where Kpow does not win: the in-app audit view shows the last seven days, so long-term retention is your audit topic’s retention settings plus whatever the webhook feeds. It records actions taken through Kpow, not requests from other clients, so keep the broker authorizer log for everything else. For how audit, RBAC and tenancy combine for shared clusters, see Kpow multi-tenancy.

To see the surface this log covers, open the Kpow demo and explore data inspect and the topic and consumer group screens on a live cluster. Data queries and the actions on those screens are the two event types the audit log and webhook record in your own deployment.

Kpow live demo

See a Kafka audit trail in action

Explore Kpow in a live environment and see the operations its audit log records against the person who ran them.

For platform and security teams who have to show who can do what.

Try the Kpow demo→

FAQ

Does Apache Kafka have audit logging?

Not as a dedicated feature. The authorizer logs its decisions to kafka.authorizer.logger, with denials at INFO and allowed requests at DEBUG, and the default config writes denials only to kafka-authorizer.log. Audit of what people did comes from the tools they use.

How do I see who deleted a Kafka topic?

If the delete came through a tool with an audit log, that log names the user. If it came from a client directly, enable DEBUG on the authorizer logger beforehand, since allowed operations are not logged at the default level, and the record will name the principal that authenticated.

Can Kafka audit logs record who read a topic’s data?

At the broker, the authorizer log at DEBUG records allowed fetch requests by principal. In tools, it depends: Kpow’s webhook can include data queries, Kafbat UI logs reads at audit level ALL, and AKHQ’s audit events cover changes only.

Where should Kafka audit logs be stored for compliance?

Somewhere with retention set by your regulatory requirement and restricted write access, typically a SIEM or object storage fed from a Kafka topic. Keep the audit topic itself on restrictive ACLs so the trail cannot be edited by the people it records.

Related reading

• Kafka: the complete guide
• Kafka stream governance
• Kafka security architecture for production
• Kafka ACL
• What is a data governance policy?
• Best tools to control destructive Kafka operations