Configure DCA Hardened Message Broker

On this page: Installed version · First-boot credentials · The Erlang cookie · The guest account and application users · Log in · Network access · Clustering · Data and logs · Upgrades · Backup and restore

Installed version

RabbitMQ 4.3.6 (package rabbitmq-server 4.3.6-1) on Erlang/OTP 27.3.4.18, installed from Team RabbitMQ's signed apt repositories the way RabbitMQ's Debian and Ubuntu install guide documents them (deb1/deb2.rabbitmq.com, plus Team RabbitMQ's Launchpad PPA for Erlang). Every package is pinned to those versions, and the rabbitmq-server package also to its sha256. The management plugin is enabled; erlang-ssh is not installed. The node is rabbit@localhost. Base OS: Ubuntu 24.04 LTS. Image built 2026-10-07; every build is gated on zero fixable HIGH or CRITICAL vulnerability findings.

sudo rabbitmq-diagnostics status      # RabbitMQ and Erlang versions, listeners, plugins

This product is based on the open-source RabbitMQ software (MPL-2.0) and is not affiliated with or endorsed by Broadcom.

First-boot credentials

No password, cookie or user ships in the image. On this VM's first boot, rabbitmq-firstboot.service generates the Erlang cookie and an administrator password before the broker first starts; rabbitmq-admin-firstboot then creates the administrator, deletes the default guest account, and proves against the running broker that the administrator signs in while a wrong password and guest/guest are refused.

The Erlang cookie

The cookie is the whole authentication boundary for Erlang distribution and for every CLI tool: whoever holds it has full control of the node, so treat it like the administrator password. rabbitmqctl, rabbitmq-diagnostics and rabbitmq-plugins run as the rabbitmq user, so use them with sudo; they find the node through NODENAME=rabbit@localhost in /etc/rabbitmq/rabbitmq-env.conf. Every node of a cluster needs the same cookie — this image never clusters, so each VM's cookie is its own.

The guest account and application users

guest is deleted on first boot, and loopback_users.guest = true stays in rabbitmq.conf, so even a re-created guest could only connect from the VM itself. Create one user per application rather than sharing admin:

sudo rabbitmqctl add_user app            # prompts for the password
sudo rabbitmqctl set_permissions -p / app '^app\.' '^app\.' '^app\.'

Log in

1. Connect with gcloud compute ssh INSTANCE_NAME --zone ZONE --tunnel-through-iap. The deployment package enables OS Login, so IAM decides who can SSH in; reading the credential files needs sudo, which OS Login grants to principals with the OS Admin Login role (roles/compute.osAdminLogin). IAP TCP forwarding needs a firewall rule that allows 35.235.240.0/20 to tcp:22 on the VM's network — the deployment package does not create one.
2. Open an SSH session that forwards the management UI, then read the administrator credential and check the node in it:

   gcloud compute ssh INSTANCE_NAME --zone ZONE --tunnel-through-iap -- -L 15672:127.0.0.1:15672
   sudo cat /root/rabbitmq-admin-credentials.txt
   sudo rabbitmq-diagnostics status

3. On your workstation, open http://localhost:15672/ and sign in as admin. Applications on the VM itself connect to amqp://USER:PASSWORD@127.0.0.1:5672/.

Network access

Most deployments only need AMQP opened; keep the management UI on loopback and reach it through the tunnel. To serve AMQP clients on your VPC:

1. Add a listener on the VM's internal IP in /etc/rabbitmq/rabbitmq.conf (sudo), keeping the loopback one, then restart and check:

   listeners.tcp.default = 127.0.0.1:5672
   listeners.tcp.vpc     = 10.128.0.5:5672      # your VM's internal IP
   
   sudo systemctl restart rabbitmq-server
   sudo rabbitmq-diagnostics listeners

2. Open the port with the deployment package's firewall toggle: in its Networking section, tick "Allow TCP port 5672 traffic from the Internet" and enter your clients' CIDR ranges under "Source IP ranges for TCP port 5672 traffic". The toggle creates one VPC firewall rule, DEPLOYMENT-tcp-5672, allowing tcp:5672 from those ranges to VMs tagged DEPLOYMENT-deployment (DEPLOYMENT is your deployment name; the VM is DEPLOYMENT-vm). Use the narrowest ranges that work — 0.0.0.0/0, which the field shows only as a format example, would publish the port through the VM's external IP. Already deployed without the toggle? Create the same rule yourself:

   gcloud compute firewall-rules create DEPLOYMENT-tcp-5672 \
     --network NETWORK --direction INGRESS --allow tcp:5672 \
     --source-ranges 10.10.0.0/24 --target-tags DEPLOYMENT-deployment

3. If you must open the management UI as well, change management.tcp.ip (for example to 0.0.0.0), restart, and use the tcp:15672 toggle with your administrators' ranges only. It is plain HTTP with basic authentication.

AMQP on 5672 and the UI on 15672 are plaintext. For anything that leaves your VPC add a TLS listener (listeners.ssl.default = 5671 with ssl_options.cacertfile, ssl_options.certfile and ssl_options.keyfile); the deployment package has no 5671 toggle, so create that firewall rule yourself.

Clustering

Not configured, deliberately. A cluster needs epmd (4369) and Erlang distribution (25672) opened between the nodes only, the same Erlang cookie on every node, and node names that resolve between them — rabbit@localhost does not. The node's data directory is named after the node, so change NODENAME before the node holds data you need.

Data and logs

Upgrades

• Recommended: deploy the newest image version, recreate your definitions on it (sudo rabbitmqctl export_definitions /root/definitions.json on the old VM, import_definitions on the new one), move producers and consumers over, and let the old queues drain.
• In place: Team RabbitMQ's repositories stay configured in /etc/apt/sources.list.d/rabbitmq.list, so sudo apt-get update && sudo apt-get install rabbitmq-server moves the broker forward. unattended-upgrades (enabled) installs Ubuntu's security updates; it does not upgrade the broker or Erlang. RabbitMQ 4.3 supports Erlang 27.0 up to 28.x, and the package will not install with Erlang 29. Read RabbitMQ's upgrade guide before crossing minor versions, and keep a definitions export.

Backup and restore

sudo rabbitmqctl export_definitions /root/definitions.json saves users, vhosts, permissions, queues, exchanges, bindings and policies — not messages; import_definitions restores them. For messages, stop the broker and snapshot the boot disk.

Monitoring

• Health: sudo rabbitmq-diagnostics -q ping → succeeds (exit status 0) — wire this into an uptime check or your monitoring agent.
• The deployment package disables the Cloud Logging and Monitoring agents in instance metadata (google-logging-enable=0, google-monitoring-enable=0), and the image pre-installs no monitoring agent. Install the Google Cloud Ops Agent if you want logs and metrics in Cloud Logging and Cloud Monitoring; nothing phones home by default.

More: install · troubleshooting · security notes · support card. Questions: support@dcassociatesgroup.com — first response within 1 business day.

This product is based on the open-source RabbitMQ software (MPL-2.0). RabbitMQ is a trademark of its owner, Broadcom; Derek Coleman & Associates Inc is not affiliated with or endorsed by Broadcom.