User is the smallest unit for dividing permissions within a TDMQ for RabbitMQ cluster. You can grant users the permissions of configuration and read/write under different vhosts.
User password is an authentication method. You can add a username and password in a client to access TDMQ for RabbitMQ clusters for message production/consumption.
Permission refers to your operation permission for exchanges and queues under a vhost, including configuration and read/write. The configuration permission controls declaring and deleting exchanges and queues. The read/write permission control reading messages from queues, sending messages to exchanges, and binding queues to exchanges.
Use Limits
There can be up to 20 users in a cluster.
Use Cases
You need to securely use TDMQ for RabbitMQ to produce/consume messages.
You need to set production/consumption permissions of different vhosts for different users.
For example, your company has departments A and B, and department A's system produces transaction data and department B's system performs transaction data analysis and display. In line with the principle of least privilege, two users can be created to grant department A only the permission to produce messages to the transaction system vhost and grant department B only the permission to consume messages. This helps greatly avoid problems caused by unclear division of permissions, such as data disorder and dirty business data.
Directions
Adding a user
Every cluster has a user named "admin" by default. You can configure permissions for this default user or create new users as needed.
2. Select Cluster > Cluster on the left sidebar, select a region, and click the ID of the target cluster to enter the Basic Info page of the cluster.
3. Select the User and Permission tab at the top of the page and click Create User on the User Management tab.
4. On the Create User page, enter the username, password, and description:
Username: Cannot be empty, should not only contain (.), must be 1-64 characters long, and can only include letters, digits, periods (.), hyphens (-), and underscores (__).
Password: Cannot be empty, must be 8-64 characters long, and must include at least two of the following: lowercase letters, uppercase letters, digits, special characters [()`~!@#$%^&*_=|{}[]:;',.?/] .
Role: Select the user role.
Role
Permission Description
none
Unable to log in to the Web console, typically applies to normal producers and consumers.
management
Web console;
Can view Vhosts under their name, as well as queues, exchanges, and bindings within;
Can view and close channels and connections under their name.
policymaker
On the basis of all Management rights:
Can view, modify, and delete policies and parameters of Vhosts under their name.
monitoring
On the basis of all Management rights:
Can view all Vhost, connection, and channel lists;
Can view node-related information (such as disk usage, memory usage, number of processes.).
administrator
Super Administrator, on the basis of all rights in Policymaker and Monitoring:
Can create and delete Vhost;
Can view, create, and delete users and permissions;
Close other users' connections.
Description (optional): Enter a user description.
5. Click Submit.
Configuring a permission
1. On the User and Permission tab, select the Permission List tab and click Configure Permission.
2. On the Configure Permission page, select the target vhost and user and set permission rules.
Permission rules can match resources through regex. For example, if you select Configuration and enter "test.-*" in the input box, then the user will be granted the permission to configure all resources with a name starting with "test-" under the current vhost.
3. Click Submit.
4. Add the username and password to the client parameters. For directions on how to add the token parameters to the client code, see Spring Boot Starter (the parameters in this document are the username and password).
5. Check whether the permission is effective. You can run the configured client to access the exchange and queue resources in the vhost and produce/consume messages according to the configured permission. Check whether a no permission error is reported, and if not, the permission has been configured successfully.
Deleting a permission
Before deleting a permission, make sure that the current business no longer uses the user to produce/consume messages; otherwise, a client exception may occur due to the failure to produce/consume messages.
1. In the User and Permission tab, click Delete in the Operation column of the target user.
Yes
No
Was this page helpful?