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. 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 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 our 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, our 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. My standing advice from our 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.

How to score a control for destructive operations

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 I 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, our 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. I set up our own AWS accounts with a read-only role for exactly this reason, so I could, in my 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

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 above (read 22 September 2026)

Option	Where it enforces	Review before execution	Granularity	Default posture	Record of the attempt	Source
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
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
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
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
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
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
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
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
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
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
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
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 (not linked)
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

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

Confluent Control Center. What it is: the management UI for Confluent Platform. How it controls destructive operations: through Confluent’s RBAC, which Confluent’s documentation, RBAC overview page, describes as role bindings managed by the Metadata Service. The same page states that “RBAC roles do not support DENY rules”, which matters when you want to carve a delete permission out of a broader role. Where it falls short: it applies to Confluent Platform deployments.

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.

Where Kpow does not win on 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 our 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.

Related reading

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