ACL menu visible in KRaft mode when ACL not enabled

[wangpi26]

Describe the bug

In Kafka 4.x KRaft mode, the ACL menu is always visible in the UI even when ACL/authorization is not enabled on the broker. This is a regression compared to ZooKeeper-based clusters where the ACL menu is correctly hidden.

Root Cause

The FeatureService detects whether ACL is enabled by calling AdminClient.describeAcls():

// ReactiveAdminClient.java
private static Mono<Boolean> isAuthorizedSecurityEnabled(AdminClient ac, @Nullable Float kafkaVersion) {
    return toMono(ac.describeAcls(AclBindingFilter.ANY).values())
        .thenReturn(true)
        .onErrorReturn(false);  // SecurityDisabledException → false
}

In ZooKeeper mode: when authorizer.class.name is not configured on the broker, describeAcls() throws SecurityDisabledException → the feature is not detected → ACL menu is hidden ✅

In KRaft mode: describeAcls() requests are always forwarded via Envelope to the active controller, which has StandardAuthorizer loaded by default (as it stores ACLs in __cluster_metadata). The call succeeds and returns an empty list instead of throwing SecurityDisabledException → the feature is falsely detected as enabled → ACL menu is always shown ❌

This behavior is inherent to the KRaft architecture (KIP-801): the controller always has a StandardAuthorizer regardless of whether the user has explicitly enabled ACL on brokers.

Expected behavior

The ACL menu should be hidden when the Kafka cluster does not have ACL/authorization enabled, regardless of whether the cluster runs in ZooKeeper or KRaft mode.

Steps to reproduce

1. Deploy a Kafka 4.x cluster in KRaft mode (split mode: process.roles=broker for brokers, process.roles=controller for controllers)
2. Do NOT configure authorizer.class.name on the broker side (ACL not enabled)
3. Connect Kafbat UI to the broker
4. Observe that the ACL menu is visible in the sidebar

Environment

• Kafka: 4.x (KRaft mode)
• Kafbat UI: v1.5.0 (also confirmed on commit afc9c91)

Suggested fix

The isAuthorizedSecurityEnabled() method should not rely solely on whether describeAcls() throws an exception. Possible approaches:

1. Check the broker config authorizer.class.name via describeConfigs() — if empty/blank, ACL is not enabled on the broker side
2. Introduce a configuration option in application.yml (e.g., kafka.clusters[].aclEnabled: true/false) to allow explicit control
3. Check if allow.everyone.if.no.acl.found is set on the broker as an additional signal

Approach 1 seems most aligned with the current auto-detection philosophy. Approach 2 provides a reliable escape hatch for edge cases.

[kapybro]

AI Summary

In Kafka 4.x KRaft mode, the ACL menu in the UI remains visible even when ACLs are not enabled, because the controller always uses StandardAuthorizer internally to manage metadata, causing describeAcls() to succeed instead of failing with SecurityDisabledException as it does in ZooKeeper mode. The suggested fix is to detect ACL enablement by checking the broker's authorizer.class.name configuration via describeConfigs(), falling back to a manual override in application.yml if needed.

[github-actions]

Hi wangpi26! 👋

Welcome, and thank you for opening your first issue in the repo!

Please wait for triaging by our maintainers.

As development is carried out in our spare time, you can support us by sponsoring our activities or even funding the development of specific issues.
Sponsorship link

If you plan to raise a PR for this issue, please take a look at our contributing guide.