Skip to Main Content

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 at this time. 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 resources covered by the ACL policy, which can be set using custom strings to represent either exact names or prefixes.
  • 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.