Learn RabbitMQ - Authorization & Access Control

#Introduction

Authentication only answers "who are you?". Authorization answers the more important question: "what are you allowed to do here?". A user may log in to the prod vhost, but can they create new queues? Read messages? Delete exchanges? All these decisions are governed by RabbitMQ's permission model.

RabbitMQ uses a three-dimensional permission model: configure, write, and read, each with a regex pattern determining which resources may be accessed. The model is simple yet expressive — and often misunderstood.

This episode dissects the permission model, applies RBAC (Role-Based Access Control) with clear roles per vhost, then dives into topic authorization — a feature that filters routing keys on topic-type exchanges so users can only publish to specific topics. By the end of the episode, you'll be able to design a secure, structured access system.

#The Permission Model

#Configure, Write, and Read

RabbitMQ allows three operation types per resource (queue, exchange):

• Configure — create and delete resources (declare queue, declare exchange).
• Write — publish messages to an exchange, or bind a queue to an exchange.
• Read — consume from a queue, or unbind resources.

Each is modeled as a regex matched against the resource name. The most common example:

rabbitmqctl set_permissions -p staging svc-order '.*' '.*' '.*'

The set_permissions command above grants configure, write, and read for all resources (.*) in the staging vhost.

#Permission Patterns and Defaults

The combination of three regexes determines granularity. For example, let a user read queues but not create them:

rabbitmqctl set_permissions -p staging analis '^$' '^$' '^analytics-.*'

The user analis cannot configure (^$ matches nothing) and cannot write, but can read all queues starting with analytics-. New users have no permissions at all by default until they are set.

#Checking and Revoking Permissions

Before changing permissions, look at the current state first. The two most used rabbitmqctl commands:

rabbitmqctl list_permissions -p staging
rabbitmqctl list_user_permissions analis

list_permissions shows the table of users along with their three regex patterns in that vhost, while list_user_permissions shows all the permissions a user has across all vhosts. Both are very helpful during security audits.

When access rights must be revoked — for example, a user is no longer used or a team member leaves — use clear_permissions:

rabbitmqctl clear_permissions -p staging analis

The clear_permissions command removes all of a user's permissions in a given vhost. Remember: the user can still log in, they just can't do anything until permissions are set again.

#RBAC Implementation

#Roles and Per-Vhost Permissions

Best practice: define clear roles, then map them to per-vhost permissions. Example roles:

• Service producer — write to exchanges, no read or configure: '^$' '^orders-.*' '^$'.
• Service consumer — read from queues, no configure: '^$' '^$' '^orders-.*'.
• Operator — configure in non-production environments: '.*' '.*' '.*'.

rabbitmqctl set_permissions -p prod svc-order-producer '^$' '^orders-.*' '^$'
rabbitmqctl set_permissions -p prod svc-order-consumer '^$' '^$' '^orders-.*'

Separate admins from application users: operations teams use the administrator tag on the vhosts they need, not on all vhosts.

#Consistent Resource Naming Schemes

Permission regexes are only useful if resource names are predictable. Establish a naming convention from the start: prefix queues with the service name and role, for example orders.worker, prefix exchanges with orders.events, and start internal system resources with internal.. With such patterns, a single regex ^orders\. can protect all order-domain resources, and per-service permissions become short and easy to review.

Consistent conventions also help avoid a common gap: a user allowed to read ^orders\. won't touch the billing. queue as long as naming doesn't overlap. Discuss this convention with the team before starting to declare resources, because renaming resources later is far more painful than establishing them from the start.

#Least Privilege

The least privilege principle: every user only gets the minimum permissions required for their work. Never copy the '.*' '.*' '.*' permissions to every user out of laziness. Start from zero and add as needed. Review permissions periodically — remove access that's no longer used, especially when team members leave or services are archived.

#Topic Authorization

#Restricting Publish by Routing Key

Topic authorization enables pattern-based permissions on topics. With this feature, the write permission is rewritten as queue-pattern/routing-key-pattern, and RabbitMQ filters publishes based on the routing key:

rabbitmqctl set_topic_permissions -p prod consumer-team \
  'amq.topic' '^log\.(info|warning)\.' '^$'

The set_topic_permissions command syntax: vhost, user, exchange, permission-pattern, permission. The line above restricts publishing to the amq.topic exchange to routing keys starting with log.info. or log.warning..

#Variable Expansion in Topic Permissions

RabbitMQ supports the {username}, {vhost}, and {client_id} variables in permission patterns. Example:

rabbitmqctl set_topic_permissions -p prod tenant-team 'amq.topic' '^tenant\.{username}\.' '^$'

The pattern above automatically restricts every user to topics owned by their own tenant — a very useful pattern for multi-tenant SaaS.

#Topic Authorization Use Cases

Topic authorization is very useful for: separating services that may only publish to their own domain topics, preventing users from writing to sensitive topics like billing, and restricting event consumption to specific categories.

#Conclusion

In episode 16 you understood the configure, write, and read permission model, put together regex patterns for per-resource control, applied RBAC with least privilege per vhost, and used topic authorization to restrict publish and consume based on routing keys.

Key takeaways:

• Configure, write, and read are RabbitMQ's three permission dimensions.
• Every permission is a regex matched against the resource name.
• New users have no permissions until explicitly set.
• RBAC maps roles to per-vhost permissions with least privilege.
• Separate admins from application users.
• Topic authorization filters routing keys on topic exchanges.
• The {username} variable makes multi-tenant permissions easy.

In the next episode we will secure transport with TLS/SSL — creating certificates and a CA, configuring AMQP over TLS on port 5671, enabling the Management UI over HTTPS, authenticating clients with certificates, and best practices for certificate rotation and cipher suites. Time to make RabbitMQ connections encrypted!