RabbitMQ Security Guide: Users, Vhosts and TLS

RabbitMQ ships with defaults built for a developer laptop: a guest user with a well-known password, an ANONYMOUS login mechanism, plaintext listeners and a management UI that stores credentials in the browser. In production the broker carries orders, payments, telemetry and job instructions, and every application that connects to it is a non-human identity with a password, certificate or token. This guide sets out how RabbitMQ authenticates and authorises clients, how to design users, virtual hosts and permissions, how to lock down the management plugin, and which settings belong in a production baseline. It is for platform and security engineers running self-managed RabbitMQ 4.x clusters.

Key takeaways

• Delete guest and remove ANONYMOUS. The default user has the password guest, and the ANONYMOUS mechanism, enabled by default, lets unauthenticated clients act as the configured anonymous user.
• One user per application, one vhost per tenant or environment. RabbitMQ's own deployment guidelines recommend both, because they make permissions, correlation and rotation workable.
• Permissions are three regular expressions per vhost. Configure, write and read patterns decide everything a client can do; .* everywhere is the most common over-grant.
• Management tags are privileged roles. administrator can create users, vhosts and permissions; give automation the monitoring tag with empty permissions, not admin.
• TLS is opt-in, and so is encryption at rest. Disable plaintext listeners with listeners.tcp = none, verify peers, protect the Erlang cookie, and encrypt the disk or the payloads because the broker does not.

How identity and access work in RabbitMQ

Every connection presents a password, JWT or X.509 certificate and names a virtual host. RabbitMQ authenticates the user, checks that the user has some permission in that vhost, then checks each operation against the user's permissions on the named exchange or queue. Authentication and authorisation are pluggable backends.

Defaults to remove on day one

• The guest user: a blank node creates the vhost / and user guest with password guest and full access to /. By default guest may only connect over the loopback interface, controlled by loopback_users. The access control guide strongly advises against setting loopback_users = none; delete the user instead. Importing definitions on first boot prevents guest being created at all.
• The ANONYMOUS mechanism: list only the mechanisms you use, for example auth_mechanisms.1 = PLAIN and auth_mechanisms.2 = AMQPLAIN (or EXTERNAL), and set anonymous_login_user = none, as the production checklist shows.
• Weak hashing for new users: the default module is rabbit_password_hashing_sha256; rabbit_password_hashing_sha512 is available and rabbit_password_hashing_md5 exists only for backwards compatibility. A changed algorithm applies to newly created users, so re-create or reset existing ones.

Users, vhosts and permissions

Virtual hosts are the tenancy boundary: the same exchange or queue name refers to a different resource in each vhost, and a user with no permission in a vhost cannot connect to it. RabbitMQ's deployment guidelines say the default vhost is fine for a cluster dedicated to one system, and recommend a separate vhost per tenant and environment, such as project1_production and project1_development, in multi-tenant clusters.

Inside a vhost, a user's permissions are a triple of regular expressions matched against resource names:

• Deny with an empty pattern: '^$' or '' matches nothing and blocks that operation type entirely.
• Server-named queues: server-generated names start amq.gen and the default exchange is checked as amq.default, so a consumer that uses exclusive server-named queues can be limited to '^(amq\.gen.*|amq\.default)$'.
• Per-user prefixes: the internal backend expands {username} and {vhost} (and {client_id} for MQTT) in patterns, so ^{username}-.* gives each identity its own namespace.
• Topic authorisation is opt-in: with the default backend, publishing to a topic exchange is always authorised if no topic permissions exist. Define topic permissions where routing keys carry meaning, especially for MQTT and STOMP clients. See the MQTT Security Guide.
• Changes are not instant: RabbitMQ may cache access control results per connection or channel, so a narrowed permission may only apply when the client reconnects.

Decision guidance: one user per application is the baseline the deployment guidelines recommend. For many instances of the same application, the guidelines describe a trade-off between per-instance credentials (better security) and shared credentials (simpler provisioning). Fleets of similar clients with fixed addresses are where X.509 or source IP range authorisation fit best; applications that already obtain tokens from an identity provider are where OAuth 2.0 fits.

Admin roles and privileged access

Management UI and HTTP API access is controlled by user tags, separately from resource permissions. New users have no tags.

• Admin is still bound by resource permissions: the management guide notes that the administrator or monitoring tag does not on its own grant access to exchanges, queues and bindings. But an administrator can grant themselves any permission, so treat the tag as full control of the cluster.
• Monitoring identities: the documented pattern is a user tagged monitoring with empty configure, write and read permissions. That lets a collector list everything without publishing, consuming or deleting.
• Erlang cookie and CLI access: nodes and CLI tools such as rabbitmqctl authenticate to each other with a shared secret, the Erlang cookie, held in a file. Anyone with the cookie and network access to the distribution port can administer the node. The production checklist says to restrict the file to the OS users that run RabbitMQ and the CLI, to generate it securely at deployment rather than copying a runtime-generated value, and to restrict access to the inter-node and CLI ports.
• Single sign-on for humans: with OAuth 2.0 enabled for the management UI, management.oauth_disable_basic_auth defaults to true, so only OAuth logins are accepted in the UI. Map identity provider groups to rabbitmq.tag: scopes and keep administrator scopes for a small group. See the OAuth Scope Design Guide.

Integrations, API tokens and service accounts

Applications, shovels, federation links, exporters and deployment pipelines all hold broker credentials. Treat each as a service account with an owner, a scope and a rotation plan. See the Service Account Security Guide.

• Seed with definitions, not ad hoc commands: the deployment guidelines recommend importing vhosts, users, permissions and topology from a definitions file. Exported definitions contain password hashes and the hashing function, and the documentation says to treat user records as sensitive. Store definition files like secrets, and prefer pre-hashed passwords to plaintext values in them.
• Keep secrets out of plaintext configuration: values prefixed with encrypted: in rabbitmq.conf are decrypted at start-up; rabbitmqctl encrypt_conf_value produces them. Use this for LDAP bind passwords, the management credentials secret and similar values, and keep the passphrase in your secrets manager.
• Federation and shovel URIs: these usually carry remote broker credentials; give them dedicated, narrowly scoped users and TLS (amqps://) URIs.
• Connection strings in application code: AMQP URIs with embedded passwords leak through repositories, CI logs and container images. Inject them at runtime from a secrets manager. See the Secrets Management Guide.
• Rotation: the access control guide describes routine rotation as changing the password (CLI or PUT /api/users/{user}), closing existing connections with rabbitmqctl close_all_user_connections, and making sure applications reconnect with the new value. For a suspected leak it recommends deleting the user, which closes all its connections, then re-creating it with a new generated password and re-granting permissions. Clearing permissions alone does not close open connections.
• Token-based clients: with OAuth 2.0, keep token lifetimes short, scope tokens to the vhost and resource (rabbitmq.write:orders/orders-exchange style) and use auth_oauth2.scope_aliases carefully, since one alias can expand into administrator scopes. See the JWT Security Guide.

TLS and network exposure

RabbitMQ listens on several ports, and the deployment guidelines split them into client ports, which applications must reach, and everything else, which should be limited to RabbitMQ nodes and CLI hosts.

• TLS-only listeners: set listeners.tcp = none and listeners.ssl.default = 5671 with ssl_options.cacertfile, certfile and keyfile.
• Verify peers: ssl_options.verify = verify_peer with ssl_options.fail_if_no_peer_cert = true rejects clients without a trusted certificate, which is also the basis for EXTERNAL authentication. See the mTLS Guide.
• Test the result: check versions and cipher suites with a tool such as testssl.sh, as the deployment guidelines suggest.
• Inter-node TLS: recommended by the production checklist; it also means CLI tools must be configured for TLS.
• Management UI headers: set management.hsts.policy (for example max-age=31536000; includeSubDomains) and review the CSP and CORS settings the management guide documents.
• Browser-stored credentials: by default the management UI stores Basic credentials Base64-encoded in the browser's localStorage, readable by anyone with developer tools or an XSS flaw. Set management.credentials_encryption_secret (identical on every node) or move the UI to OAuth 2.0.
• Data at rest: RabbitMQ does not encrypt message payloads or metadata on disk. Use volume encryption, end-to-end payload encryption by the applications, or both. See the Disk Encryption Guide.

Logging and detection

Failed authentication closes the connection and writes to the server log; for example, a remote attempt with guest is logged as "PLAIN login refused: user 'guest' can only connect via localhost". Log categories such as log.connection.level control connection logging detail. For structured audit, the rabbitmq_event_exchange plugin republishes internal events to the topic exchange amq.rabbitmq.event, with an empty body and details in message metadata.

Only trusted consumers should have read access to amq.rabbitmq.event, as the plugin documentation warns. Ship events and server logs to the SIEM; for metrics, the management guide recommends Prometheus over the management UI for production. See the SIEM Guide.

Metrics that show the controls are working:

• Users with .* configure, write and read permissions in production vhosts (target zero outside the deployment identity).
• Number of users with the administrator tag per cluster.
• Share of client connections using TLS, and plaintext listeners enabled (target zero).
• Application users whose password is older than your rotation interval.
• Authentication failures per day per user, against a baseline.
• Clusters where guest exists or ANONYMOUS is enabled (target zero).

Hardening baseline

Rolling it out

1. Inventory: list users, tags, vhosts, permission patterns, enabled plugins, listeners and which applications connect with which user (connection names and client properties help).
2. Split shared users: create one user per application with least-privilege patterns, move applications over one at a time, and watch user.authentication.failure and permission errors in the server log.
3. Remove defaults: delete guest and drop ANONYMOUS from auth_mechanisms in a staging cluster first; roll back by restoring the previous configuration file.
4. Introduce TLS: enable 5671 alongside 5672, migrate clients, then set listeners.tcp = none. Keep the plain listener configuration ready to restore during the change window.
5. Lock down management: move the UI to TLS and OAuth 2.0 or credential encryption, reduce administrator tags, and firewall 15672/15671.
6. Codify: manage users, permissions and policies through definitions in version control, with secrets injected at deploy time.

Small versus large estates: a single cluster for one system can keep the default vhost and internal users, provided guest and ANONYMOUS are gone and TLS is on. Multi-tenant or regulated clusters benefit from vhost per tenant and environment, OAuth 2.0 for humans, certificates or tokens for applications, and event exchange audit into the SIEM.

Common misconfigurations

• Re-enabling remote guest: setting loopback_users = none to make a quick test work, then promoting that configuration. Default accounts with known passwords are ATT&CK T1078.001.
• Leaving ANONYMOUS enabled: any client that does not send credentials connects as the anonymous user.
• Shared .* users: one user with full configure, write and read in every vhost, used by every service, so a single leaked connection string allows reading, purging and deleting all queues.
• Plaintext AMQP and management: passwords and message payloads on 5672 and 15672 can be captured on the network (ATT&CK T1040, T1557).
• Management UI on the internet: 15672 reachable from anywhere, often with an administrator user and Basic auth.
• Definitions and URIs in repositories: definition exports with password hashes, and AMQP or federation URIs with embedded passwords, committed to Git (ATT&CK T1552.001).

Framework mapping

Practitioner checklist

• Delete guest (or import definitions on first boot) and confirm loopback_users is not none.
• Remove ANONYMOUS from auth_mechanisms and set anonymous_login_user = none.
• Create one user per application with least-privilege configure, write and read patterns, and no management tag.
• Use a vhost per tenant and environment on shared clusters.
• Limit administrator to named operators and the deployment pipeline; use monitoring with empty permissions for collectors.
• Enforce TLS with listeners.tcp = none, verify_peer and fail_if_no_peer_cert, and enable inter-node TLS.
• Generate and protect the Erlang cookie and firewall ports 4369, 25672 and 35672-35682 to cluster and CLI hosts.
• Put the management UI behind TLS with OAuth 2.0 or credential encryption, HSTS, and operator-only network access.
• Store definitions and connection strings as secrets, use encrypted: config values, and rotate application passwords on a schedule.
• Enable the event exchange, restrict who can read it, and alert on authentication failures and user, tag and permission changes.

Standards and references

• RabbitMQ: Authentication, Authorisation, Access Control
• RabbitMQ: Deployment Guidelines (Production Checklist)
• RabbitMQ: Management Plugin
• RabbitMQ: TLS Support
• RabbitMQ: Networking and Port Access
• RabbitMQ: OAuth 2.0 Authentication Backend
• RabbitMQ: Event Exchange Plugin
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Kafka Security Guide · Kafka Credentials Security Guide · MQTT Security Guide · Service Account Security Guide