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.
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.
At a glance
Eleven options are scored here on this page's five weighted criteria, 90 points in all. The rubric is weighted: Real identity counts three times, Retention and export counts three times, and Layer covered, Reads as well as writes and Broker overhead count once. The five listed first, of eleven, each out of 90: Kpow 69, which takes its best score on Real identity (9 out of 10) and its lowest on Layer covered (6 out of 10); Kafbat UI 60; Amazon MSK logs and CloudTrail 55; AKHQ 55; Klaw 54.
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 Factor House 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, Factor House’s 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 Factor House’s team, Chad Harris 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: INFOSo 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.
Options by layer
Rank 1 Kpow
69 out of 90 Total
Try Kpow in the live demo No signup needed.
- Layer
- Control plane
- Audit topic
- __oprtr_audit_log
- In-app view
- Last seven days
- Layer covered
- 6 out of 10
- Reads as well as writes
- 7 out of 10
- Real identity ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Broker overhead
- 8 out of 10
- Retention and export ×3 weight, this criterion counts 3 times toward the total
- 7 out of 10
Why these scores for Kpow
- Layer covered 6 out of 10
- Kpow covers the control plane only, and the page says “It records actions taken through Kpow, not requests from other clients”, which is why the authorizer log and MSK score higher.
- Reads as well as writes 7 out of 10
- Mutations are always logged, and data queries through the webhook’s query setting, which needs configuring, the same as Kafbat UI’s ALL level.
- Real identity 9 out of 10
- The user from your IdP is named, with the RBAC decision, and the record also holds the RBAC policies evaluated, the most identity detail in the column.
- Broker overhead 8 out of 10
- Collection sits outside the broker path and adds none, and criterion 4 says collection outside the request path “costs the cluster nothing”.
- Retention and export 7 out of 10
- An internal topic and webhooks to any endpoint hold the trail, and the passage on where Kpow does not win says the UI shows seven days while long-term retention is your topic settings, so MSK scores higher.
Layer. Control plane.
Covers. Every user action, recorded in an audit log retained in an internal Kafka topic, __oprtr_audit_log, and shown 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.
Strengths. 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. 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.
Weaknesses. 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.
Source. Kpow data governance (audit log).
Staying patched. Kpow’s release notes name the CVEs each release remediates, and the 96.4 image built on 5 August 2026 bundles 311 dependencies of which one carries a high or critical advisory, none of them published before that release. That is not a claim to patch faster than a community project: Kpow’s own dependency remediation has run from 14 to 128 days, and the current image still ships CVE-2026-75595 in netty, a 9.1 critical public since 19 August 2026, unpatched. What a licence buys here is not a different deployment model, because Kpow is self-hosted too. It is a company contracted to ship the fix. Every dependency figure on this page was read on 24 September 2026 from the published artefacts and from nvd.nist.gov.
Compare Kpow vs AKHQKpow vs Kafbat UI
Rank 2 Kafbat UI
60 out of 90 Total
- Layer
- Control plane
- Default level
- ALTER_ONLY
- Layer covered
- 6 out of 10
- Reads as well as writes
- 7 out of 10
- Real identity ×3 weight, this criterion counts 3 times toward the total
- 8 out of 10
- Broker overhead
- 8 out of 10
- Retention and export ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
Why these scores for Kafbat UI
- Layer covered 6 out of 10
- Kafbat UI covers the control plane only.
- Reads as well as writes 7 out of 10
- By default it logs writes, and reads at level ALL.
- Real identity 8 out of 10
- Records name the logged-in user.
- Broker overhead 8 out of 10
- Nothing lands on the brokers.
- Retention and export 5 out of 10
- Audit records go to a Kafka topic or the console, and the topic has no keys, must not be compacted, and reading it is up to you.
What it is. An open-source Kafka UI.
Covers. Operations done in the UI, to a Kafka topic, the console or both. Its audit level is ALTER_ONLY by default, and ALL also logs read operations.
Weaknesses. The audit topic has no keys, so its docs warn it must not be compacted, and reading it is up to you.
Source. Kafbat UI audit log.
Staying patched. Kafbat UI released v1.5.0 in April 2026 and has not shipped since. In the 157 days since, at least 20 high or critical advisories have been published against libraries that release bundles, including the same netty critical CVE-2026-75595 that the current Kpow image carries. Only 150 of its 266 bundled jars resolved to a Maven coordinate, so that count is a floor and the state of the release itself is unmeasured. Kafbat does publish a security policy, which AKHQ and Kafdrop do not, and the one CVE filed against its own code, CVE-2025-49127, was already fixed in the release that preceded the advisory. Six releases in two years.
Compare Kpow vs Kafbat UIAKHQ vs Kafbat UIConduktor vs Kafbat UIKafbat UI review
Amazon MSK logs and CloudTrail
55 out of 90 Total
- Layer
- Broker and API
- Delivery
- CloudWatch Logs, S3, Data Firehose
- Layer covered
- 7 out of 10
- Reads as well as writes
- 6 out of 10
- Real identity ×3 weight, this criterion counts 3 times toward the total
- 4 out of 10
- Broker overhead
- 6 out of 10
- Retention and export ×3 weight, this criterion counts 3 times toward the total
- 8 out of 10
Why these scores for Amazon MSK logs and CloudTrail
- Layer covered 7 out of 10
- Broker and API are both covered, with authorizer logs plus cluster API calls in CloudTrail, two surfaces in one service.
- Reads as well as writes 6 out of 10
- Authorizer logs and API calls give it the same read coverage as the authorizer log.
- Real identity 4 out of 10
- The record names the principal or the IAM identity, which the page calls “the same principal limitation”.
- Broker overhead 6 out of 10
- AWS manages it, but it is still broker-side logging, and the cost is not stated.
- Retention and export 8 out of 10
- Logs go to CloudWatch, S3, Firehose, and the page says “delivery to durable AWS storage is configuration, not code”.
What it is. MSK can deliver broker and authorizer logs to CloudWatch Logs, S3 or Data Firehose, and its API calls, such as cluster changes, go to CloudTrail.
Strengths. Delivery to durable AWS storage is configuration, not code.
Weaknesses. MSK only, and the same principal limitation.
Source. Amazon MSK logging.
Rank 4 AKHQ
55 out of 90 Total
- Layer
- Control plane
- Default
- Off
- Layer covered
- 6 out of 10
- Reads as well as writes
- 2 out of 10
- Real identity ×3 weight, this criterion counts 3 times toward the total
- 8 out of 10
- Broker overhead
- 8 out of 10
- Retention and export ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
Why these scores for AKHQ
- Layer covered 6 out of 10
- AKHQ covers the control plane only.
- Reads as well as writes 2 out of 10
- Writes are logged, and the page says “Reading data is not in that list”.
- Real identity 8 out of 10
- The record names the logged-in user.
- Broker overhead 8 out of 10
- It adds none.
- Retention and export 5 out of 10
- Events go to a Kafka topic you nominate, but the page’s own prose says there is no UI for reading the trail, “so you build the consumer”.
What it is. An open-source Kafka UI.
Covers. Its audit docs list topic creation, config change, partition increase and deletion, producing and deleting records, emptying topics, consumer group offset changes and deletes, schema changes and connector changes. Reading data is not in that list.
Strengths. Events go to a Kafka topic on a cluster you nominate.
Weaknesses. Off by default, no reads, and no UI for reading the trail, so you build the consumer.
Source. AKHQ audit configuration.
Staying patched. AKHQ has no CVE filed against its own code, and that is the wrong number to plan against. Release 0.28.0, cut on 6 August 2026, bundles 270 libraries and 18 of them carry a high or critical advisory. Sixteen were already public, with fixed versions already on Maven Central, on the day it shipped, and five are netty advisories Kpow had remediated three weeks earlier in 96.2: CVE-2026-44249, CVE-2026-45416, CVE-2026-45674, CVE-2026-47691 and CVE-2026-50010. The oldest has been open 108 days. That is exposure and remediation latency rather than a working attack, and every figure resolves against the published jar and nvd.nist.gov. Four releases in two years, and no security policy at any path GitHub reads.
Rank 5 54 out of 90 Total
- Layer
- Control plane
- Type
- Self-service portal
- Layer covered
- 5 out of 10
- Reads as well as writes
- 2 out of 10
- Real identity ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Broker overhead
- 8 out of 10
- Retention and export ×3 weight, this criterion counts 3 times toward the total
- 4 out of 10
Why these scores for Klaw
- Layer covered 5 out of 10
- Klaw covers the control plane, but the page notes “it records requests made in Klaw, not direct changes”.
- Reads as well as writes 2 out of 10
- Requests and approvals are logged, not data reads.
- Real identity 9 out of 10
- Each record names the requester and approver, two named people.
- Broker overhead 8 out of 10
- None falls on the brokers.
- Retention and export 4 out of 10
- The trail stays in Klaw’s database, and the page describes no export.
What it is. An open-source self-service portal.
Covers. An audit of all topic, ACL, schema and connector requests and their approvals.
Weaknesses. It records requests made in Klaw, not direct changes or data reads.
Source. Klaw.
Staying patched. Klaw is Apache-2.0 under Aiven, with a published security policy and the patch record to match it. Three CVEs, and the fix shipped the same day for CVE-2026-25999 in February 2026 and the next day for the two published in May 2026. Seven releases in two years, most recently v2.10.6 in September 2026. Community-maintained is not the same as unmaintained, and this is the end of that range where it shows.
Rank 6 Google Cloud Managed Service for Apache Kafka
52 out of 90 Total
- Layer
- Service API
- Logs
- Admin activity, data access
- Layer covered
- 6 out of 10
- Reads as well as writes
- 7 out of 10
- Real identity ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
- Broker overhead
- 6 out of 10
- Retention and export ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
Why these scores for Google Cloud Managed Service for Apache Kafka
- Layer covered 6 out of 10
- The service API layer is covered, and Google Cloud only.
- Reads as well as writes 7 out of 10
- Admin activity and data access logs both exist, though data access logs must be enabled.
- Real identity 5 out of 10
- A Google identity is named, and the page does not say whether that is a person or a service account.
- Broker overhead 6 out of 10
- Google manages it.
- Retention and export 6 out of 10
- The trail lands in Cloud Logging, and the page describes no retention or export beyond that.
What it is. Cloud Audit Logs for the managedkafka.googleapis.com service, split into admin activity and data access logs.
Weaknesses. Google Cloud only, and data access logs must be enabled.
Rank 7 Confluent Server audit logs
confluent.io
47 out of 90 Total
- Layer
- Broker
- Scope
- Confluent Platform only
- Layer covered
- 6 out of 10
- Reads as well as writes
- 6 out of 10
- Real identity ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Broker overhead
- 5 out of 10
- Retention and export ×3 weight, this criterion counts 3 times toward the total
- 7 out of 10
Why these scores for Confluent Server audit logs
- Layer covered 6 out of 10
- Coverage is the broker layer only, and Confluent Platform only.
- Reads as well as writes 6 out of 10
- Authorization decisions for protected actions are recorded, on by default, though the page does not break them down into reads and writes.
- Real identity 3 out of 10
- Records name the principal, and the page says it “sees principals rather than the people behind a tool”.
- Broker overhead 5 out of 10
- It runs in the broker, and the page gives no cost beyond that.
- Retention and export 7 out of 10
- Audit records go to Kafka topics as CloudEvents, then out through sink connectors.
What it is. Confluent Platform’s audit logging, built on the Confluent Server Authorizer. Confluent’s documentation, Audit Log Concepts page, says audit logs record “the runtime decisions of the permission checks” for ACLs and RBAC into Kafka topics, as CloudEvents, and are enabled by default.
Weaknesses. Confluent Platform only, and like any broker log it sees principals rather than the people behind a tool.
Source. Confluent’s documentation.
Compare Apache Kafka vs Confluent Kafka
Rank 8 Apache Ranger audit
44 out of 90 Total
- Layer
- Broker
- Requires
- Ranger as your authorizer
- Layer covered
- 6 out of 10
- Reads as well as writes
- 6 out of 10
- Real identity ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Broker overhead
- 5 out of 10
- Retention and export ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
Why these scores for Apache Ranger audit
- Layer covered 6 out of 10
- Broker layer; one audit store across the data platform, but only once Ranger is the authorizer.
- Reads as well as writes 6 out of 10
- Access decisions are recorded, which the page does not break down into reads and writes.
- Real identity 3 out of 10
- The record names the principal.
- Broker overhead 5 out of 10
- The plugin runs in the broker, with no cost figure given.
- Retention and export 6 out of 10
- Ranger’s audit store holds the trail, and the page describes no export path.
What it is. Ranger’s Kafka plugin replaces the authorizer, and Ranger centralises auditing of access decisions across the platform.
Strengths. One audit store for Kafka and the rest of a Hadoop-style data platform.
Weaknesses. You adopt Ranger as your authorizer to get it.
Sources. Apache Ranger, plugin source.
Staying patched. Apache Ranger is Apache-2.0 and actively developed, with a published security policy, and it carries the exposure of a large, long-lived project: an NVD keyword search returns 36 CVEs across its history. It publishes tags rather than GitHub releases, so the build you run is one you cut and patch yourself.
Rank 9 Apache Kafka authorizer log
40 out of 90 Total
- Layer
- Broker
- Default output
- Denials only, at INFO
- Layer covered
- 7 out of 10
- Reads as well as writes
- 6 out of 10
- Real identity ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Broker overhead
- 3 out of 10
- Retention and export ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
Why these scores for Apache Kafka authorizer log
- Layer covered 7 out of 10
- The broker layer is what it covers, and the page calls it “complete for the protocol” and “the only record of requests from clients that never touch a tool”.
- Reads as well as writes 6 out of 10
- Reads are logged at DEBUG, with denials only at the default INFO, so they need a level change that adds a line per request.
- Real identity 3 out of 10
- The connection principal is all it names, and criterion 3 says the broker sees the tool’s service account, not the person.
- Broker overhead 3 out of 10
- It grows with request rate at DEBUG, and criterion 4 calls DEBUG on every broker “audit most teams switch off again”.
- Retention and export 5 out of 10
- You ship the log files yourself, and the page says “it needs a log pipeline to be useful”.
What it is. The kafka.authorizer.logger output of whichever authorizer you run.
Covers. Broker decisions, reads and writes, by principal.
Strengths. Free, complete for the protocol, and the only record of requests from clients that never touch a tool.
Weaknesses. Denials only by default, the principal is whatever authenticated, and at DEBUG the volume grows with request rate, so it needs a log pipeline to be useful.
Source. Apache Kafka source, above.
Factor Platform lineage
26 out of 90 Total
Get early access to Factor Platform
- Layer
- Lineage
- Status
- Early access
- Layer covered
- 5 out of 10
- Reads as well as writes
- 1 out of 10
- Real identity ×3 weight, this criterion counts 3 times toward the total
- 1 out of 10
- Broker overhead
- 5 out of 10
- Retention and export ×3 weight, this criterion counts 3 times toward the total
- 4 out of 10
Why these scores for Factor Platform lineage
- Layer covered 5 out of 10
- Factor Platform lineage covers the lineage layer only, which the page’s own prose calls “the lineage layer, not user actions”, and lineage is “not audit”.
- Reads as well as writes 1 out of 10
- Under OpenLineage tooling, this page’s table gives data flow, not access.
- Real identity 1 out of 10
- Under OpenLineage tooling, records name jobs and datasets, with no person.
- Broker overhead 5 out of 10
- It depends on emitter, under OpenLineage tooling.
- Retention and export 4 out of 10
- Lineage lands in a lineage backend, not an audit trail, under OpenLineage tooling.
What it is. Factor House’s unified control plane for Kafka, Flink and Iceberg, currently in early access, which maps governance metadata embedded in Avro and JSON schemas to OpenLineage dataset facets. The approach is written up in data lineage support in Factor Platform.
Covers. The lineage layer, not user actions.
Rank 11 Conduktor Console
conduktor.io
63 out of 90 Total
- Layer
- Control plane
- Type
- Commercial Kafka console
- Layer covered
- 6 out of 10
- Reads as well as writes
- 4 out of 10
- Real identity ×3 weight, this criterion counts 3 times toward the total
- 8 out of 10
- Broker overhead
- 8 out of 10
- Retention and export ×3 weight, this criterion counts 3 times toward the total
- 7 out of 10
Why these scores for Conduktor Console
- Layer covered 6 out of 10
- Conduktor Console covers the control plane only.
- Reads as well as writes 4 out of 10
- Console events are logged, and the page does not say whether data reads are recorded.
- Real identity 8 out of 10
- Events name the logged-in user.
- Broker overhead 8 out of 10
- The brokers carry none.
- Retention and export 7 out of 10
- The trail sits in the UI and in a Kafka topic in CloudEvents, browsed, filtered and exported.
What it is. A commercial Kafka console. Conduktor’s documentation, audit logs page, says Console audit events can be browsed and filtered in the UI and exported from a Kafka topic in CloudEvents format, with event types such as topic delete carrying the topic’s prior state.
Source. Conduktor’s documentation.
Tools compared
| Rank | Tool | Layer | Reads as well as writes | Real identity | Broker overhead | Retention and export | Source |
|---|---|---|---|---|---|---|---|
| 1 | 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 |
| 2 | Kafbat UI | Control plane | Writes by default, reads with level ALL |
The logged-in user | None | Kafka topic or console | Kafbat docs |
| 3 | Amazon MSK | Broker and API | Authorizer logs, API calls in CloudTrail | Principal or IAM identity | Managed by AWS | CloudWatch, S3, Firehose | AWS docs |
| 4 | Google Managed Kafka | Service API | Admin activity and data access logs | Google identity | Managed by Google | Cloud Logging | Google Cloud docs |
| 5 | AKHQ | Control plane | Writes only | The logged-in user | None | Kafka topic you nominate | AKHQ docs |
| 6 | Klaw | Control plane | Requests and approvals | The requester and approver | None | Klaw's database | GitHub |
| 7 | Confluent Server audit logs | Broker | Authorization decisions for protected actions | Principal | Runs in the broker | Kafka topics, then sink connectors | Confluent's documentation |
| 8 | Apache Ranger | Broker | Access decisions | Principal | Runs in the broker plugin | Ranger's audit store | ranger.apache.org |
| 9 | 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 |
| 10 | OpenLineage tooling | Lineage | Data flow, not access | Jobs and datasets | Depends on emitter | Lineage backend | openlineage.io |
| 11 | Conduktor Console | Control plane | Console events | The logged-in user | None | UI and a Kafka topic in CloudEvents | Conduktor's documentation |
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 Factor House’s 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.
Kpow does not win on every point. 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 Settings, Audit log, Mutations tab: each row shows when the action ran, the user, the action, its subjects and whether it succeeded, with a view button to open the full record. A Queries tab sits beside it.
Product demo · 3 min
Apache Kafka audit logging: Kpow demo
Chad Harris walks through audit logging in Kpow: how every meaningful action is recorded on a Kafka topic you can inspect directly, tracing an entry back to the exact query and data it exposed, and forwarding audit events to Slack, Teams, or a SIEM via webhook.
Kpow live demo
See the access policies behind the audit trail
Open the Kpow demo, then Settings and Profile, to see the role policies that allow or deny each action a user can take in Kpow.
For platform and security teams who have to show who can do what.
Try the Kpow demoFAQ
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.
How these tools were scored
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Layer covered counts once, Reads as well as writes counts once, Real identity counts three times, Broker overhead counts once and Retention and export counts three times, for a total out of 90. Real identity and Retention and export count three times here, because a trail that names a shared service account instead of a person, or that rolls off before anybody reviews it, does not answer the question an auditor asks. Layer covered, reads as well as writes and broker overhead count once. This page is published by Factor House, which makes Kpow. Every option is scored on the same rubric and the same sources: Kpow's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Kpow ranks first on its total of 69 out of 90. The other options follow by total. Conduktor Console is listed last whatever its total; on its total of 63 it would place second.