Configuring Topic Read/Write Permission
Last updated:2026-01-20 16:52:40
Scenarios
After SASL authentication is enabled for a TDMQ for CKafka (CKafka) instance, only authenticated SASL users can access CKafka resources. Access control list (ACL) policies support setting different topic production/consumption permissions for different SASL users, achieving permission isolation between users, and enhancing user access control during public/private network transmission.
Constraints and Limitations
The access method set during the addition of a routing policy only affects the authentication method during access. The set ACL policy is global. The two work together to collectively ensure the security and access control of the cluster.
If you use both SASL and PLAINTEXT methods to access CKafka, the ACLs set for topics will still be effective. To ensure that PLAINTEXT access remains unaffected, add read/write permissions for all users for the topics that require PLAINTEXT access.
If a topic is already being used by other cloud products (for example, Cloud Log Service (CLS) log shipping, Serverless Cloud Function (SCF) message dumping, and consumption by big data EMR components), enabling the ACL policy will restrict permissions for these integrated capabilities, directly causing these capabilities to become unavailable. Proceed with extreme caution. For such scenarios, it is recommended to produce identical data to another topic for separate processing, rather than configuring a unified ACL policy on the same topic.
Configuring an ACL Policy
Step 1: Enabling SASL Authentication
Before configuring an ACL policy, you need to enable SASL authentication for the instance. For differences between access methods and specific operation steps, see Network Connection Instructions.
Step 2: Creating User
Note:
Only users authenticated via SASL can trigger subsequent ACL policy verification. If you already have an appropriate user, you may skip this step.
Securely store your username and password to prevent leakage. When producing and consuming messages on the client, you will need to configure these parameters.
1. Log in to the CKafka console.
2. In the left sidebar, select Instance List. Select an appropriate region and click the ID of the target instance to go to the basic instance information page.
3. On the basic instance info page, choose ACL Policy Management > User Management. Click New and enter the username and password.
Username: It needs to comply with the naming rules. It can only contain letters, digits, underscores (_), hyphens (-), and periods (.).
Password: It needs to meet the password rules. It must contain at least two of the following items: lowercase letters, uppercase letters, digits, and special characters [()`~!@#$^&*-_=|{}[]:;',.?/].
4. Click Submit to complete the creation. On the user management list page, you can copy the username.
Step 3: Configuring Topic Read/Write Permission
An ACL policy is a set of user-defined permission rules that allow/deny a user to read or write topic resources via IP addresses.
1. Log in to the CKafka console.
2. In the left sidebar, select Instance List. Select an appropriate region and click the ID of the target instance to go to the basic instance information page.
3. On the basic instance information page, choose ACL Policy Management > Policy List. Click Batch Configuration to go to the ACL policy configuration page.
4. In the Match Mode section, configure the topic resource matching rules.
Note:
Instances of Kafka version 2.4.1 and later support three methods to select effective topics: batch selection, fuzzy matching by prefix, and preset rule. Instances of Kafka versions earlier than 2.4.1 only support two methods: batch selection and preset rule. You can view the configuration instructions for different matching methods via the following tabs:
Used to select multiple topics that require the same ACL policy configuration. You can batch select the topics to be configured directly in the Select Topic section.
Note:
In a single batch operation, the total bytes of names of all selected topics must be below 255 bytes. If the limit is exceeded, the operation will fail. It is recommended to perform the operation in batches, with no more than 10 topics selected in each batch.
Supports fuzzy matching by topic name prefix and configuring the same ACL policy for matched topics. After the rules are created, this ACL policy will be applied to both existing and new topics named with the specified prefix.
Rule Name: Set a name for the fuzzy matching rule. It needs to comply with the naming rules. It must start with a letter, and can only contain letters, digits, underscores (_), hyphens (-), and periods (.).
Prefix: Enter matching characters, and the list of matched topics will be automatically displayed below.
Preset an ACL policy. After creating an ACL policy, you can select and configure this ACL policy in Advanced Settings when creating a topic. For details, see Creating a Topic.
Rule Name: Set a name for the preset rule. It needs to comply with the naming rules. It must start with a letter, and can only contain letters, digits, underscores (_), hyphens (-), and periods (.).
Automatically Applied to All Subsequently Added Topics: Once this option is enabled, subsequently created topics will be automatically configured with this rule.
Note:
Each instance can be configured with a maximum of 100 preset rules.
5. In the ACL Policy section, set user access rules.
Note:
After permissions are configured, if no allow policy is configured, access is denied by default.
If the same object is configured with both allow and deny permissions, the deny permission takes precedence.
Parameter | Description |
Permission | ACL policy operation permissions are divided into two categories: allow rules and deny rules. If only allow rules are configured, other IP addresses except those allowed will be unable to connect to the instance. If only deny rules are configured, other IP addresses except those denied require allow rules to be set before they can connect to the instance. If both allow rules and deny rules are configured, only IP addresses in the allow rules can connect to the instance, while all other IP addresses will be unable to connect to the instance. |
User | Select the user for whom you want to set permissions. If no user is selected, permissions are added for all users by default. |
IP/IP range | Enter the IP address for which you want to set permissions. You can enter multiple IP addresses or IP ranges, separated by ;. If the IP address field is empty, permissions are added for all IP addresses by default.Instances of version 3.2.x do not currently support configuring IP ranges. |
Policy | Select the action for which the policy takes effect, namely reading or writing messages to the topic. Currently, selecting both read and write simultaneously is not supported. If necessary, create two separate ACL policies. |
6. Click Submit to complete the ACL policy creation.
7. Verify whether the permissions are effective. You can access CKafka through SASL access points and consume messages using the PLAIN/SCRAM mechanism (see SDK Reference).
Managing ACL Policies
The ACL policies matched for the topic are displayed under the Resource tab of Policy List. Preset ACL policies created via Fuzzy Matching by Prefix and Preset Rules are displayed under the Preset Rules tab.
Viewing and Modifying Topic Permissions
1. On the ACL Policy List page, select the Resource tab. The list displays the topics created under the current instance.
2. Click Add ACL Policy in the Operation column of the target topic to view the configured policy details of the topic. On this tab, you can perform the following operations:
Click Create Policy in the upper-left corner to create an ACL policy directly under the current topic.
Click Delete in the Operation column to delete the ACL policy configured for the topic. After it is deleted, the rule will no longer take effect.
Viewing and Modifying Preset Rules
1. On the ACL Policy List page, select the Preset Rule tab. The list displays the preset rules created under the current instance.
2. Click Details in the Operation column of the target rule to view preset rule details, and choose whether to enable Applied to All Newly Added Topics.
3. Click Delete in the Operation column of the target rule to delete the preset rule.
For preset rules created in different ways, after they are deleted, the handling method for historically effective rules differs. Details are as follows:
Fuzzy Matching by Topic Name Prefix: For topics that have historically matched this rule, the rule will become invalid immediately.
Preset Rule: For topics that have historically matched this rule, the rule will remain effective.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback