Best tools to control destructive Kafka operations

The best tools to control destructive Kafka operations work at two layers: the broker, where delete.topic.enable, ACLs and a pluggable authorizer such as Apache Ranger or OPA decide what any client may do, and the workflow, where GitOps tools, Klaw and Kafka UIs with review steps decide whether a permitted change should run. No single tool covers both.

Apache Kafka itself gives you an on-off switch for topic deletion and an authorizer. Everything else on this page is built on top of those two, which is why the rubric starts with where a control enforces, not with how good its interface looks. For the wider governance picture, the complete Kafka guide and the page on stream governance cover the layers this page does not.

What counts as a destructive Kafka operation

A destructive Kafka operation is any change the cluster will carry out immediately and cannot reverse on its own: deleting a topic, deleting or truncating records, resetting a consumer group’s offsets, shrinking retention, or reassigning partitions to the wrong brokers. Each one is a single Admin API call, and Kafka’s authorizer answers each one with allow or deny, nothing in between.

Deleting a topic removes the log and every record in it. Resetting offsets leaves the data alone but moves a consumer group’s position, so a downstream service either replays weeks of events or skips them. Shortening retention.ms looks like a config edit and turns into data loss at the next log cleanup, hours after the change was approved. If you need the mechanics of removing data deliberately, Tom Crowley, Factor House’s founding engineer, walks through deleting records in Kafka with topic deletion, truncation and tombstones side by side. That is the diagnosis side of this job. This page is the choosing side.

Offset resets deserve their own mention because they are the destructive operation people do not think of as destructive. Chad Harris’s standing advice from the Kafka operational issues talk is to use latest in production and make offset resets a deliberate, manual operation. A control that treats an offset reset as a routine edit has missed half the problem. The tools for doing resets safely are compared in Kafka offset management tools, and topic create, delete and config tools in Kafka topic management tools.

Tools compared

Each cell says why, not just whether. “Tool-only” in the first column means the control does not stop a client that talks to the cluster directly.

Controls for destructive Kafka operations, scored on the five criteria explained under how these tools were scored (read 22 September 2026)

Rank	Option	Where it enforces	Review before execution	Granularity	Default posture	Record of the attempt	Source
1	Kpow	Tool-only	Yes. Any action can carry a Stage effect, and an admin who also holds that permission approves or denies it	Per action (TOPIC_DELETE, TOPIC_TRUNCATE, GROUP_EDIT and so on) and per resource, with wildcard patterns	Anything no policy allows is implicitly denied	Every request, approval and denial in the audit log, with webhook notifications	Kpow staged mutations
2	delete.topic.enable=false	Broker. Deletion requests are rejected for every client	None. It is a switch, not a review	Topic deletion only, cluster-wide, all or nothing	Protection is off by default: delete.topic.enable defaults to true	Rejected requests surface as client errors, nothing more	Apache Kafka broker configs
3	CreateTopicPolicy and AlterConfigPolicy	Controller. Validates create-topic and alter-config requests from any client	None. Code decides, no person does	Whatever your Java class checks, for creates and config changes only. There is no delete policy	Not set: both default to null	Rejections go back to the client. Logging is up to your class	Apache Kafka broker configs, KIP-108
4	Klaw	Tool-only	Yes. Topic create, update and delete, and ACL requests, all go through approval	Per team and environment, with more than 35 permissions	Requests need an approver by design	Audit of all topic, ACL, schema and connector requests	Klaw
5	OPA authorizer plugin	Broker. Each request is sent to an OPA policy	None at request time. Policy changes can go through code review	Anything a Rego policy can express	Fail-closed if OPA is unreachable, by default	Whatever OPA decision logging you configure	opa-kafka-plugin
6	Native Kafka ACLs	Broker, through the configured authorizer	None	Per principal, operation and resource, with literal or prefixed patterns	Resources with no ACL are restricted to super users, unless allow.everyone.if.no.acl.found=true	Denials logged at INFO to kafka-authorizer.log by default	Apache Kafka authorization and ACLs
7	Apache Ranger Kafka plugin	Broker. Replaces the authorizer with Ranger's	None	Central policies across Kafka and the rest of the data stack	Depends on the policies you define	Ranger's centralised audit of access decisions	Apache Ranger, plugin source
8	Terraform with the Kafka provider	Tool-only	Yes, as plan review on a pull request	Per topic and ACL resource, plus prevent_destroy on critical topics	Plans will destroy a removed resource unless prevent_destroy is set	Git history and plan output	terraform-provider-kafka, Terraform lifecycle
9	kafka-gitops and Julie Ops	Tool-only	Yes, as a pull request	Topics, ACLs and derived service ACLs from a desired-state file	kafka-gitops has a --no-delete flag. Both projects are effectively unmaintained	Git history	kafka-gitops, Julie Ops
10	Strimzi Topic and User Operators with GitOps	Tool-only for people who can still reach the cluster directly. Topics and ACLs are Kubernetes resources	Yes, as a pull request on the resource, if your repo requires review	Per topic and per user resource	Deleting a KafkaTopic deletes the topic, guarded by a finalizer while the operator runs	Git history of the resource	Strimzi deploying guide
11	Kafbat UI	Tool-only	None	RBAC per resource and action, plus a per-cluster read-only flag	Read-only is off by default	Audit to a Kafka topic or the console, alter operations only by default	Kafbat UI docs
12	AKHQ	Tool-only	None	Roles per resource type and action, scoped by regex patterns	Security is disabled by default, so an anonymous user has full access until you enable it	Opt-in audit events written to a Kafka topic you choose	AKHQ docs
13	Confluent Control Center	Confluent Platform components, through role bindings managed by the Metadata Service	None. A permission model, not a review step	Role bindings per resource, but its RBAC overview says "RBAC roles do not support DENY rules"	Not stated	Not stated for Control Center itself	Confluent's documentation, RBAC overview page
14	Conduktor Console	Tool-only	For cross-team access requests. Its docs say topic creation that passes policy needs no approval	Application ownership plus RBAC	Depends on setup	Console audit log, exportable from a Kafka topic	Conduktor's documentation, Self-service concepts page

The pattern in the table is the point. The broker-level rows are the only ones that stop a direct kafka-topics.sh --delete, and none of them offers a human review. Every row that offers a review is tool-only. A production setup that takes destructive operations seriously uses one of each.

Kafka UIs and management platforms with role-based guardrails

Access control and governance tools

GitOps and infrastructure as code

Mutation interceptors and proxies

Kafka’s only built-in request interceptors are the two policy plugins, set on the controller:

create.topic.policy.class.name=com.example.TopicCreatePolicy
alter.config.policy.class.name=com.example.AlterConfigPolicy

Apache Kafka’s broker config reference says both “run on the controller instead of the broker”. A create-topic policy can enforce replication factor and naming. An alter-config policy can refuse a retention.ms below a floor, which is the one config-level destructive change a broker-side plugin can actually block. There is no delete-topic policy. KIP-170 proposed one and is marked retired, superseded by KIP-201, which is still under discussion. For deletes, your broker-side options are delete.topic.enable, ACLs, or a custom or third-party authorizer such as Ranger or OPA.

How Factor House approaches it

Kpow treats a destructive action as something to route rather than just permit or refuse. An RBAC policy can give any action one of three effects: Allow, Deny or Stage. A staged action does not run. It becomes a request that an admin reviews under Settings, and the staged mutations documentation is specific that the admin approving it “must also be allowed to invoke” the same mutation, so an approver cannot sign off on something they could not have done themselves. A webhook can notify the right channel when a request arrives, and the full history of approvals and denials lands in the audit log.

policies:
  - resource: ["cluster", "*", "group", "payments_*"]
    effect: "Stage"
    actions: ["GROUP_EDIT"]
    role: "kafka-users"
  - resource: ["cluster", "*"]
    effect: "Allow"
    actions: ["GROUP_EDIT"]
    role: "kafka-admins"

That example, adapted from the RBAC documentation, makes offset changes on payments groups a two-person operation for everyone outside the admin role. Where multiple policies apply to one resource, Deny wins, and where no policy matches, the action is implicitly denied. Bulk actions, such as deleting 300 topics in one request, are disabled by default and need both BULK_ACTION and the underlying permission, so you can let someone delete a topic without letting them delete a hundred. Temporary policies cover the break-glass case: an admin grants an elevated action for a fixed window, capped at seven days by default, and cannot grant anything above their own permissions.

Kpow does not win on every point of this rubric. It is a tool-only control, like every workflow option here. Kpow’s own Kafka credentials need enough ACLs to do what its users are allowed to do, so a person who holds those credentials outside Kpow bypasses every staged mutation. Pair it with broker ACLs that keep human principals away from Delete and Alter. Kpow also has no config guardrails of its own for retention floors or partition limits. Tom was direct about that with Factor House’s own team: “We don’t offer retention + configuration guardrails”. An AlterConfigPolicy on the controller is the place for that today. Multi-tenancy does add a narrower guardrail, because a user inside a tenant can only create resources that fall within that tenant’s prefixes or suffixes.

The same Stage effect works in Flex for Apache Flink. The Flex staged mutations documentation shows FLINK_JOB_EDIT staged for a users role, so editing or cancelling a running job goes through the same request, review and audit path. For how tenancy, RBAC and staged approvals fit together across teams, see Kpow multi-tenancy.

To see where these controls apply, open the Kpow demo and explore the topic, consumer group and ACL screens on a live cluster, then decide which actions on them your own roles should get as Allow, Deny or Stage.

Kpow live demo

Try approval-gated Kafka changes

Explore Kpow in a live environment and see the destructive operations that staged mutations can hold for approval.

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

Try the Kpow demo→

FAQ

Can I stop a Kafka topic from being deleted at the broker?

Yes. Set delete.topic.enable=false on every broker, and deletion requests are rejected for all clients. It is a read-only broker setting, so changing it needs a restart, and it blocks legitimate deletes too. For selective protection, deny the Delete operation with ACLs or a custom authorizer instead.

Does RBAC in a Kafka UI stop someone deleting a topic from the CLI?

No. A UI’s RBAC only governs requests made through that UI. The broker only sees the credentials on the connection, so the CLI path is closed by broker ACLs, delete.topic.enable, or an authorizer such as Ranger or OPA.

What is the difference between a staged mutation and an ACL?

An ACL decides whether a principal may run an operation at all, and the broker answers immediately. A staged mutation takes an operation the user is allowed to request and holds it until an admin who also holds that permission approves or denies it, with the decision recorded in the audit log.

Is there a Kafka policy plugin that blocks topic deletion?

Not in Apache Kafka. CreateTopicPolicy and AlterConfigPolicy exist, and a proposed delete policy in KIP-170 was retired without shipping. Deletes are controlled with delete.topic.enable, ACLs, or a replacement authorizer.

How these tools were scored

Every option below is scored on the same five criteria, in this order. The figure above separates the two kinds of control, because most tools on this page are one or the other and the difference decides what they can catch.

1. Where it enforces. A control on the broker or controller holds for every client, including a shell on a jump host with admin credentials. A control inside a tool holds only for requests that go through that tool, which makes this criterion more important than any feature list. In the same talk Chad Harris described how even teams running CI and automated GitOps keep a break-glass path for changing broker config directly when something is on fire, and the change that goes in through that door does not always make it back into GitOps. Every workflow tool on this page has that side door, and the broker-level controls are what close it.

2. Review before execution. Does a second person see the specific request before it runs? A permission check cannot do this, because it only knows who is asking. A pull request, a Klaw request or a staged mutation can.

3. Granularity. Can you allow a topic config change but deny a topic delete, or allow offset resets only on groups with a given prefix? Tom Crowley, Factor House’s founding engineer, has put the difference plainly when explaining Kpow to customers: Kafka ACLs govern what a principal can do on the cluster, and Kpow’s own RBAC is “much more granular and work[s] across all resources configured (ksql, connect, schema etc) - unlike Kafka’s ACLs”. The finer the action model, the less you have to take away to block the dangerous part.

4. Default posture. What happens before anyone configures anything? A tool that ships wide open turns every new deployment into a destructive-operations risk until someone notices. Chad Harris set up Factor House’s own AWS accounts with a read-only role for exactly this reason, so he could, in his words at the time, “fearlessly inspect the environment state and reverse engineer some terraform, without fear of deleting everything”. Read-only by default is the posture to look for.

5. Record of the attempt. When a destructive request is approved, denied or blocked, is there a record with the user, the request and the outcome? A denial nobody can see does not help the next review. Kafka audit logging tools compares where those records can come from.

F1 Permission check or review step

Permission check (ACLs, RBAC, authorizer) Review before execution (staged request, pull request)

What it decides Whether this principal may run this operation on this resource Whether this specific, already-permitted request should run now

Who acts The person or service that sent the request, immediately A second person, after reading the request

When a mistake is caught Only if the principal lacked the permission in the first place Before the change reaches the cluster, if the reviewer spots it

What a bypass looks like Any credential that holds the permission, from any client Any path to the cluster that does not go through the review tool

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: Where it enforces counts once, Review before execution counts three times, Granularity counts once, Default posture counts once and Record of the attempt counts three times, for a total out of 90. Review before execution and Record of the attempt count three times here, because a destructive operation nobody approved and nobody logged is the one you find out about from a customer. Where it enforces, granularity and default posture count once, and the first of those is where the tool-only options on this page are weakest. 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 80 out of 90. The other options follow by total. Conduktor Console is listed last whatever its total; on its total of 46 it would place sixth.

Related reading

• Kafka: the complete guide
• Kafka stream governance
• Kafka ACL
• RBAC roles
• Kafka security architecture for production
• Kafka offset management tools