RabbitMQ

Overview

RabbitMQ is a messaging and streaming broker. Its management user interface and HTTP API normally use ports 15672 or 15671. AMQP and other messaging protocols use separate TCP ports. Management and message traffic need different routes.

RabbitMQ can expose sensitive application data or administrative functions. A Pomerium route adds identity-aware policy before a user reaches the selected endpoint while the service keeps its own detailed permissions.

Pomerium controls who can establish the selected route to RabbitMQ. RabbitMQ remains responsible for its application, protocol, data, and service-level permissions.

How it works

Create a separate Pomerium route for each required HTTP, TCP, UDP, or SSH endpoint. Do not send internal cluster, gossip, replication, or control-plane traffic through a user route.

Use a web route for browser traffic and a supported Pomerium client or native access flow for non-HTTP traffic. Keep service-level TLS, authentication, and authorization active.

Create an HTTPS route for the management endpoint and distinct TCP routes for only the messaging protocols that users need. Keep clustering and Erlang distribution traffic private.

Example

Operators use a Pomerium HTTPS route for the RabbitMQ management interface. An approved client uses a separate TCP tunnel for AMQP. RabbitMQ keeps users, virtual hosts, exchanges, queues, and permissions.

Considerations

• A TCP-only page is incomplete because it omits the management web interface. An HTTP-only page is incomplete because it omits message protocols.
• Applications and brokers need noninteractive credentials. Preserve RabbitMQ TLS, users, virtual hosts, and permissions.
• Pomerium checks TCP and WebSocket policy when the connection starts. A later policy change does not terminate an established connection.
• For TCP tunnels, place Pomerium behind an L4 or TCP edge. Any HTTP proxy in front of Pomerium must forward CONNECT traffic.