Message queue security

Message queuing services facilitate inter-process communication between OpenStack services. Transport Layer Security (TLS) is the industry-standard cryptographic protocol designed to secure internet communications with confidentiality, integrity, and authentication.

In RHOSO deployments, TLS is enabled by default across service communication.

Security and hardening goals in RHOSO for messaging include the following:

  • Protect message traffic from tampering.
  • Prevent eavesdropping on communications.
  • Restrict trust chains.

These goals are achieved through the following best practices:

  • Use the platform-default TLS messaging posture.
  • Use cert-manager to manage the lifecycle of your certificates.
  • Use Kubernetes Secret and RBAC controls.
  • Enforce operator-governed trust and endpoint exposure policies.

Encryption in RHOSO is handled by OpenShift-native mechanisms and cert-manager, instead of by manual RabbitMQ configuration.

RabbitMQ exposes the following additional endpoints beyond Advanced Message Queuing Protocol (AMQP):

  • 15672: HTTP management API, non-TLS.
  • 15671: HTTPS management API, TLS.
  • 15692: Prometheus exporter, non-TLS.
  • 15691: Prometheus exporter, TLS.

When hardening your RHOSO deployment, you can restrict or disable non-TLS management and monitoring endpoints, where feasible. Use NetworkPolicies and service exposure controls to limit access to non-TLS ports (15672, 15692), and prefer TLS ports (15671, 15691) for operational tools.

RabbitMQ uses port 25672 for inter-node clustering communication. This traffic is separate from client AMQP connections. In multi-replica deployments, verify whether inter-node encryption is explicitly enabled and enforce it where required by policy.

TLS enablement alone is not sufficient for hardening. You should define and validate protocol and cipher policy, such as the following:

Minimum protocol version
Enforce TLS 1.2 or higher.
Deprecated protocols
Disable TLS 1.0 and TLS 1.1.
Cipher posture
Prefer modern Authenticated Encryption with Associated Data (AEAD) cipher suites and remove deprecated or weak options.
Verification
Validate negotiated protocol and cipher from a trusted administration context with openssl s_client or equivalent tools. Apply these checks to both client messaging paths and administrative endpoints where TLS is enabled.

Messaging security best practices
Copy link

You can secure messaging transport with some of the following best practices:

Validate issuer and CA hierarchy
  • Check issuer objects and verify that the internal roots are present and correct.
  • Confirm that RabbitMQ certificates are issued by the Certificate Authority (CA) that you expect.
Enforce custom enterprise CAs when required
  • Ensure custom trust roots are propagated consistently across control-plane components.
Monitor certificate rotation
  • Track certificate readiness and renewal events.
  • Configure alerts on renewal failures before expiration windows.
Restrict access to secrets and namespaces
  • Audit who can read or mount transport URL and certificate secrets.
  • Validate RBAC boundaries in the openstack namespace.
Audit runtime TLS usage
  • Confirm active RabbitMQ listeners and verify Advanced Message Queuing Protocol (AMQP) TLS listener usage.
  • Verify transport URLs and consistently use 5671 and ssl=1.
Harden management and monitoring paths
  • Restrict the non-TLS ports (15672, 15692) by using NetworkPolicies and service exposure controls.
  • Prefer the TLS ports (15671, 15691) where operationally required.
Address availability and clustering
  • Verify RabbitMQ replica count for production HA posture.
  • In multi-replica setups, include checks for inter-node traffic hardening.

Messaging hardening verification
Copy link

You can use the following checks to validate messaging hardening status:

Confirm RabbitMQ listeners
$ oc exec -n openstack <rabbitmq-pod> -- rabbitmq-diagnostics listeners

where:

<rabbitmq-pod>

Specifies the name of your RabbitMQ pod.

You can expect to see results such as the following:

  • AMQP TLS listener on 5671 present.
  • Plain AMQP 5672 absent for hardened/default posture.
  • Management or monitoring listeners reviewed for TLS or non-TLS exposure.
Verify certificate readiness and issuer mapping
$ oc get certificates -n openstack \
  -o custom-columns='NAME:.metadata.name,ISSUER:.spec.issuerRef.name,READY:.status.conditions[0].status'

You can expect to see results such as the following:

  • RabbitMQ certificates, for example rabbitmq-svc, rabbitmq-cell1-svc are READY=True.
  • Issuer alignment matches intended CA hierarchy, for example rootca-internal.
Verify issuer inventory
$ oc get issuers -n openstack

You can expect to see the following result:

  • Issuers include rootca-internal, rootca-libvirt, rootca-ovn, and rootca-public.
Inspect transport URL format safely
$ oc get secret -n openstack <transport-url-secret> \
  -o jsonpath='{.data.transport_url}' | base64 -d | \
  sed -E 's#(://)[^:]+:[^@]+@#\1<redacted>:<redacted>@#'

where:

<transport-url-secret>

Specifies the appropriate transport URL secret value for your environment.

You can expect to see results such as the following:

  • URL includes port 5671 and ssl=1.
  • Credentials are redacted before sharing logs or tickets.
Validate negotiated TLS protocol/cipher
$ openssl s_client -connect <rabbitmq-service-or-route>:5671 -tls1_2

where:

<rabbitmq-service-or-route>

Specifies the appropriate RabbitMQ service or route value for your environment.

You can expect to see results such as the following:

  • A successful TLS handshake.
  • The negotiated protocol or cipher meets policy requirements.