Scope RabbitMQ virtual hosts and permissions

The fix

# A vhost per application, and a user scoped to it
rabbitmqctl add_vhost orders
rabbitmqctl add_user orders_app "$(openssl rand -base64 24)"

# configure / write / read — each a regex of resource names
rabbitmqctl set_permissions -p orders orders_app '^orders\.' '^orders\.' '^orders\.'

Why it matters

By default the replacement for guest is often a single user with .* .* .* on the default vhost / — full control of everything. That’s guest with a different name.

A leaked or compromised broker credential with full permissions can read every message on every queue, delete queues, reconfigure exchanges to redirect messages, and set up its own bindings to siphon traffic. Message brokers sit between your services, so control of the broker is control of the data flowing between them.

Scoping cuts that down. A credential limited to one virtual host and one set of resource names can touch only its own application’s messaging — a leak is bounded to that one app, not the whole estate.

Virtual hosts are the isolation boundary

A virtual host is a fully separate namespace: its own exchanges, queues, bindings and permissions. A user granted access to vhost orders cannot see anything in vhost billing — not the queues, not the messages, not that it exists.

That makes vhosts the right separation for multi-application or multi-tenant brokers. One vhost per application, each app’s user granted access only to its own:

rabbitmqctl add_vhost orders
rabbitmqctl add_vhost billing
rabbitmqctl set_permissions -p orders orders_app '.*' '.*' '.*'
# billing_app has no permissions on orders at all

Running everything in the default / vhost means every credential shares one namespace, and permission regexes are the only separation — which works, but is more error-prone than a hard vhost boundary.

The three permissions are not read/write/admin

This is the part people get wrong, because the names don’t mean what they look like. RabbitMQ permissions are three regular expressions, matched against resource names (queues and exchanges):

Permission	Grants the right to…	On resources matching
configure	create and delete queues/exchanges, set policies	the configure regex
write	publish to an exchange, bind a queue	the write regex
read	consume from a queue, get messages	the read regex

So set_permissions -p / app '.*' '.*' '.*' grants configure, write and read on everything — the .* is a name pattern, not an access level. To let an app publish and consume its own queues but not create or delete anything:

rabbitmqctl set_permissions -p orders orders_app '^$' '^orders\.' '^orders\.'

'^$' for configure matches nothing — the app cannot create or delete queues, which is usually correct: queues are created at deploy time by a privileged account, and the runtime app only publishes and consumes. That separation is the RabbitMQ equivalent of splitting DDL from runtime in Postgres.

User tags are separate from permissions

Tags control management access, not messaging:

Tag	Grants
administrator	full management, all vhosts, user management
monitoring	read-only management across all vhosts
management	management UI for own vhosts only
(none)	AMQP only — no management UI at all

An application user should have no tag — it needs to publish and consume, not log into the management UI. Giving an app the administrator tag so it “just works” hands it the whole broker’s management surface on top of its messaging.

Verify it worked

List permissions across all vhosts:

rabbitmqctl list_vhosts
for v in $(rabbitmqctl list_vhosts --quiet | tail -n +1); do
  echo "== $v =="; rabbitmqctl list_permissions -p "$v"
done

A user with .* .* .* on / is the finding unless it’s a deliberate admin account.

Check tags — no application should be administrator:

rabbitmqctl list_users

Then prove a scoped user’s limits. As that user, try something outside its scope:

# Publishing to a resource outside its write regex should fail
rabbitmqctl eval 'rabbit_access_control:check_resource_access(...).' 2>/dev/null

Simpler: use the HTTP API as the app user to hit another vhost:

curl -su orders_app:PASS http://localhost:15672/api/queues/billing \
  -o /dev/null -w '%{http_code}\n'

Expect 403 or 404 — the user can’t see the billing vhost.

Before you apply this

Tightening permissions breaks the application at its next broker operation — a publish or consume failing mid-run, not a clean startup error. And RabbitMQ’s access-denied errors close the channel, which many clients surface as a generic connection drop rather than a permissions message.

Find out what the app actually does before scoping it. Watch its operations:

rabbitmqctl list_connections user
rabbitmqctl list_queues name vhost   # what exists, and where

The specific things people over-restrict:

• configure for apps that declare their own queues on startup. Many clients call queue.declare every connection. If the app creates its queues rather than relying on a deploy step, it needs configure on those names — or move queue creation to a privileged setup step and keep the runtime user on '^$'.
• Dead-letter and retry exchanges. An app using DLX needs write access to the dead-letter exchange’s name too, which is easy to miss because it’s not in the obvious path.

Migrating from a broad user to scoped ones is staged: create the vhost and scoped user, point one app at it, confirm it works, repeat, then remove the broad credential.

Moving apps into separate vhosts is more disruptive — queues in / don’t exist in the new orders vhost, so it’s effectively a migration of the messaging topology, not just a permission change. Plan it as a topology change with the app team, not a quick rabbitmqctl command.

Related

• Replace the guest user — the users these permissions apply to.
• Secure the management UI — where tags take effect.