RabbitMQ Users and Permissions

RabbitMQ controls access through a user and permission system. Every client that connects to the broker must authenticate with a username and password. Permissions then determine exactly which resources that user can access and what actions they can perform within each virtual host.

Default User

RabbitMQ ships with one default user: guest with password guest. This user has full administrator access but can only connect from localhost by design. Never expose the guest user on a production server accessible from the network — always create dedicated users.

User Tags

Tags control what a user can see and do in the Management UI and HTTP API. RabbitMQ supports five built-in tags:

Tag             Access Level
-------------------------------------------
(none)          Can only connect via AMQP. No management UI access.
management      Can log into the UI and view own vhosts.
policymaker     Can manage policies and parameters on their vhosts.
monitoring      Can view all connections, channels, and node stats.
administrator   Full access to everything including user and vhost management.

Creating a User

CLI

rabbitmqctl add_user alice strongpassword123
rabbitmqctl set_user_tags alice monitoring

Management UI

  1. Go to Admin → Users → Add a user.
  2. Enter the username and password.
  3. Select the appropriate tag(s).
  4. Click Add user.

HTTP API

curl -u guest:guest -X PUT http://localhost:15672/api/users/alice \
  -H "Content-Type: application/json" \
  -d '{"password":"strongpassword123","tags":"monitoring"}'

Setting Permissions

After creating a user, grant them permissions on a specific virtual host. Permissions have three components, each a regular expression:

  • Configure: Which resource names the user can declare, delete, or modify.
  • Write: Which exchanges the user can publish to, and which queues they can bind.
  • Read: Which queues the user can consume from, and which exchanges they can bind from.
rabbitmqctl set_permissions -p /production alice "^orders.*" "^orders.*" "^orders.*"

This grants Alice permission to configure, write to, and read from any resource whose name starts with orders in the /production vhost.

Permission Examples

Full access to everything in /production:
  rabbitmqctl set_permissions -p /production alice ".*" ".*" ".*"

Read-only consumer (can only read from queues, cannot publish or configure):
  rabbitmqctl set_permissions -p /production reader "" "" ".*"

Publish-only producer (can publish to exchanges, no read or configure):
  rabbitmqctl set_permissions -p /production publisher "" ".*" ""

Access to specific queues only:
  rabbitmqctl set_permissions -p /production bob "^(orders|payments)$" "^(orders|payments)$" "^(orders|payments)$"

Listing Users and Permissions

# List all users
rabbitmqctl list_users

# List permissions for a specific vhost
rabbitmqctl list_permissions -p /production

# List permissions for a specific user across all vhosts
rabbitmqctl list_user_permissions alice

Output of list_users:

Listing users...
guest    [administrator]
alice    [monitoring]
bob      []

Changing a Password

rabbitmqctl change_password alice newstrongpassword456

Force a password change after any suspected credential compromise. Old sessions using the previous password remain active until their connections are closed — close them manually via the Management UI or the HTTP API.

Revoking Permissions

# Remove all permissions for alice on /production
rabbitmqctl clear_permissions -p /production alice

This removes Alice's access to the /production vhost completely. She can no longer connect to that vhost even if she still has a valid user account. Existing connections are not immediately dropped — they continue until they close or time out.

Deleting a User

rabbitmqctl delete_user bob

Deleting a user removes their account and all their permissions across all vhosts. Active connections using that user's credentials are not immediately closed.

Security Best Practices

  • Delete or disable the guest user in production: rabbitmqctl delete_user guest
  • Use strong passwords: At least 16 characters with mixed case, numbers, and symbols.
  • Use one user per service: Each microservice gets its own RabbitMQ user. If one service is compromised, its credentials are scoped only to the queues it needs.
  • Restrict permissions with regex: Do not give every service ".*" access. Scope each user to only the queues and exchanges it legitimately needs.
  • Use TLS for authentication: For the highest security, use certificate-based authentication instead of passwords. This eliminates the risk of password interception on the network.
  • Audit periodically: Review user lists and permissions quarterly to remove stale accounts.

Topic-Level Permissions (MQTT)

For MQTT clients, RabbitMQ supports topic-level permissions that restrict which MQTT topics a user can publish to or subscribe to. This is separate from the standard AMQP permission system and is configured via the rabbitmq_auth_backend_http or similar plugins for fine-grained MQTT access control.

External Authentication

RabbitMQ supports pluggable authentication backends beyond the built-in user database:

  • LDAP plugin: Authenticate users against an existing LDAP or Active Directory server.
  • HTTP auth plugin: Delegate authentication to an external HTTP endpoint.
  • OAuth 2.0: Integrate with OAuth 2.0 identity providers for token-based authentication.

Summary

RabbitMQ's user and permission system controls who can connect and what they can do. Users are assigned tags that control management UI access. Permissions are granted per vhost using regex patterns for configure, write, and read access. Always delete or secure the default guest user in production. Create one dedicated user per service with the minimum permissions required. Use strong passwords, TLS, or external authentication backends for production deployments.

Leave a Comment

Your email address will not be published. Required fields are marked *