ApsaraMQ for RabbitMQ supports open-source RabbitMQ authentication and permissions to control access at the vhost level.
Limitations
-
Open-source authentication and permission management is available only for newly purchased instances. Existing instances cannot switch to this mode. Supported instance types:
-
Pay-as-you-go Instances (Serverless series):
-
(Exclusive) Pay-by-Provisioned-Capacity-and-Elastic-Traffic
-
-
Subscription instances:
-
Enterprise Platinum Edition
-
Enterprise Edition
-
-
-
The default guest account cannot be created or managed.
-
User tag-based permission management is not supported. For details on managing permissions via the console or OpenAPI, see RAM access control.
-
You must choose either open-source authentication or Alibaba Cloud Resource Access Management (RAM) when configuring an instance. This choice is irreversible.
-
Enabling open-source authentication on an exclusive-cluster serverless instance prevents downgrading to a shared instance.
How it works
ApsaraMQ for RabbitMQ controls access at the vhost level. You assign configure, write, and read permissions to exchanges and queues using regular expressions:
-
.*grants access to all resources. -
^$matches the empty string, blocking all access. -
'^(amq\.gen.*|amq\.default)$'allows access to system resources and the default exchange.
The following table describes how typical AMQP 0-9-1 operations map to these permissions:
|
AMQP 0-9-1 operation |
configure |
write |
read |
|
|
exchange.declare |
(passive=false) |
exchange |
||
|
exchange.declare |
(passive=true) |
|||
|
exchange.declare |
(with AE) |
exchange |
exchange (AE) |
exchange |
|
exchange.delete |
exchange |
|||
|
queue.declare |
(passive=false) |
queue |
||
|
queue.declare |
(passive=true) |
|||
|
queue.declare |
(with DLX) |
queue |
exchange (DLX) |
queue |
|
queue.delete |
queue |
|||
|
exchange.bind |
exchange (destination) |
exchange (source) |
||
|
exchange.unbind |
exchange (destination) |
exchange (source) |
||
|
queue.bind |
queue |
exchange |
||
|
queue.unbind |
queue |
exchange |
||
|
basic.publish |
exchange |
|||
|
basic.get |
queue |
|||
|
basic.consume |
queue |
|||
|
queue.purge |
queue |
Access control has two stages:
-
Vhost access: A connecting client specifies a vhost. The server verifies the user has access and rejects the connection otherwise.
-
Resource operations: The server checks whether the user has the required permissions for each exchange or queue operation.
Network security
When using open-source authentication and permission management, ApsaraMQ for RabbitMQ enhances security as follows:
|
Network type |
Solution |
|
VPC |
Open-source auth + private endpoint |
|
Internet |
Open-source auth + public IP whitelist + Access open-source authentication instances over a public endpoint |
If you configure a public IP whitelist but connections to your ApsaraMQ for RabbitMQ instance are still rejected, check the following before you conclude that the whitelist is not working:
-
The whitelist takes effect at the AMQP protocol layer, not the ICMP layer. A successful ping to the instance IP address does not indicate that the whitelist is working. If an AMQP connection is blocked, check the whitelist configuration instead of relying on ping results.
-
Whitelist entries must be specified as CIDR blocks, such as
x.x.x.x/30. The system does not accept a single IP address or anx.x.x.x/32entry. -
To troubleshoot, check the IP entries in the whitelist list in the console and confirm that they use the correct CIDR format.
User and permission management
ApsaraMQ for RabbitMQ lets you create users and manage permissions in the console. For step-by-step guidance, see Permissions.