Manage Kafka ACLs

This article introduces the basic concepts of Kafka ACL functionality, related constraints, and how to enable and use ACL functionality in an AutoMQ instance.

Kafka ACL Concepts

Overview

Apache Kafka® provides ACL functionality to support client authentication and authorization. AutoMQ is 100% compatible with Apache Kafka®, so you can enable and use Kafka ACL functionality when using an AutoMQ instance.

When using Kafka ACL, note the following constraints:

Version Constraints: Ensure that the AutoMQ instance version is >= 1.10.x. Otherwise, you need to upgrade the version before enabling ACL.

Optional Enablement: By default, ACL is not enabled in AutoMQ instances. Users can manually enable ACL when creating an instance or later.

Access Protocol: AutoMQ currently only supports accessing clusters through the VPC internal network using the SASL_PLAINTEXT protocol.

Resource Types: AutoMQ currently supports ACL permission control for Kafka Cluster, Topic, Consumer Group, and Transaction ID resource types. DelegationToken type is not supported yet. If needed, please refer to Obtaining Services▸ to contact us.

ACL Users

In the Kafka ACL feature, users are the principal for ACL identity recognition. Kafka clients transmit their user identity through the access protocol, and the Kafka server performs identity recognition and confirms the user corresponding to the current client request before proceeding with subsequent permission verification and other operations.

It is important to distinguish between Kafka ACL users and AutoMQ environment members:

Scenario Comparison	Kafka ACL Users	AutoMQ Environment Members
Usage Scenario	Kafka client API, CLI access	AutoMQ environment web access
Coverage Scope	Applied to a single Kafka instance	Applied to the entire environment, can operate across instances

ACL Authorization Policy

Apache Kafka defines the scope of resources different users can access and the list of operations they can perform through authorization policies. Refer to Apache Kafka's design documentation. The authorization policy of an AutoMQ instance contains the following information:

Parameter	Description
Resource Type	Description: The resource type refers to the categories of Kafka resources that the Kafka ACL policy applies to. The current supported types are: Cluster: Defines operation permissions at the instance (cluster) level, such as viewing cluster configuration and viewing cloud information. Topic: Defines operation permissions at the Topic level, such as delete, subscribe, send message, etc. Consumer Group: Defines permissions for Kafka Consumer clients to join a Group and participate in message reception. TransactionID: Defines permissions for using transactional messages.
Resource Name	Description: The resource name defines the scope of the ACL policy. By setting a custom string convention, it can be an exact name or a prefix. Restrictions: Refer to Restrictions▸.
Match Type	Description: The match type describes whether the resource name field in the current ACL rule is an exact match or a prefix match. Types: literal: Exact match, i.e., the resource name is the actual effective name. prefixed: Prefix match, i.e., the resource name is a prefix of the actual effective resource.
Operation Group	Description: An operation group is a combination of fine-grained atomic authorization operations (Operation) in Apache Kafka. Each operation group contains multiple Kafka operations. Using operation groups can simplify the authorization process for a series of typical use cases. Refer to the table below for the mapping relationship between operation groups and Kafka ACL operations.
Authorization Type	Description: Apache Kafka ACL supports the following two types of authorization: ALLOW: This ACL policy allows users to perform the aforementioned operations on the associated resources. DENY: This ACL policy denies users the ability to perform the aforementioned operations on the associated resources. Note: DENY authorization policies are similar to a blacklist capability, have exclusivity characteristics, and have a higher priority than ALLOW.
Access Source	Description: The access source defines that the current ACL policy is only effective for the specified IP source. It is not effective for IP sources that do not match. Restrictions: The access source only supports exact IP addresses, not CIDR subnets or domain names.

AutoMQ defines operation groups to simplify the authorization process. The mapping between operation groups and Kafka operations is shown in the table below:

Resource Type	Operation Group	Included Operations	Recommended Scenarios
Cluster	All	Alter AlterConfigs ClusterAction Create Describe DescribeConfigs All	The "All" operation group grants full operational permissions on the Kafka cluster (instance). Generally recommended for Kafka UI and CLI tool users.
Topic	All	Alter AlterConfigs Create Delete Describe DescribeConfigs Read Write	The "All" operation group grants all operational permissions on a single Topic. Generally recommended for users who need both production and subscription permissions.
	Produce	Create Write Describe	The "Produce" operation group grants the minimum operation scope for producing messages to a single Topic. Recommended for message-producing users.
	Consume	Read Describe	The Consume operation group defines the minimum scope of operations for subscribing to messages from a single Topic. It is recommended to grant this permission to users subscribing to messages. If you need to subscribe to messages using a Consumer Group, you must authorize both the Topic's Consume operation group and the target Consumer Group.
Consumer Group	All	Delete Describe Read	The All operation group defines all operation permissions for using a specific Consumer Group. It is recommended to grant this permission to users subscribing to messages. If you need to subscribe to messages using a Consumer Group, you must authorize both the Consumer Group and grant the Consume operation group permission for the target Topic.
TransactionID	All	Describe Write	The All operation group defines the permissions to read status and commit transactions for a specific TransactionID. It is recommended to grant this permission to users who need to send transactional messages.

Using Kafka ACL

To use the Kafka ACL feature in an AutoMQ instance, follow the process below:

Note that:

• When creating an instance, ACL is disabled by default, allowing clients to access the cluster anonymously with all permissions through the PLAINTEXT protocol.

• After enabling ACL, the PLAINTEXT protocol will still be available, but you should immediately switch all client applications to use SASL_PLAINTEXT endpoints, which support identity and permission verification, to prevent unauthorized access. Once the switch is complete, disable the PLAINTEXT protocol endpoints.