A blog to share security, networking and cloud related technology information as @vCloudernBeer picked up on his search for his destiny in the cloud. (LinkedIn: https://www.linkedin.com/in/chowanthony)

Saturday, November 15, 2014

OpenStack Series: Part 15 - Messaging and Queuing system in OpenStack

OpenStack uses a message broker to coordinate
operations and status information among services. The Message Broker Service typically runs on the controller node

All OpenStack services has a RESTful API for external entities to communicate with them. Within each services AMQP (Advanced Message Queue Protocol) is used for the sub task to communicate with each other.

RabbitMQ seems to be the most accepted backend. Red Hat used to favor using Qpid for its distribution of OpenStack but in the latest release Red Hat switch to using RabbitMQ as the default.

RabbitMQ and Qpid are AMQP brokers. Explanation of the AMQP architecture can be found here. ZeroMQ is used in OpenStack as a message queuing service backend but is not exactly a AMQP broker.

AMQP is a family of messaging protocols, while ZeroMQ/ØMQ is a library of
messaging functionality. We do not use AMQP directly but rather
download and use a specific AMQP implementation such as OpenAMQ or RabbitMQ.

What about SecurityAccording to OpenStack Documentation: The
message queue is a critical piece of infrastructure that supports a number of
OpenStack services but is most strongly associated with the Compute service.

One
of the larger concerns that remains is that many systems have access to this
queue and there is no way for a consumer of the queue messages to verify which
host or service placed the messages on the queue. An attacker who is able to
successfully place messages on the queue is able to create and delete VM instances,
attach the block storage of any tenant and a myriad of other malicious actions

In the above diagram the "Management" I believe is the Message Broker Service.

When we talk about security in OpenStack, Keystone is always in the picture. User or services authenticate themselves to the Keystone server and obtain a token. For messaging, this token is used so that the Message Broker Service will know if the sender of the message has the authorization to perform such an action.It is also recommended to secure the transport layer of the message with SSL.

AMQP based solutions (Qpid and RabbitMQ) support transport-level
security using SSL.

ZeroMQ messaging does not natively support SSL, but
transport-level security is possible using labelled IPSec or CIPSO
network labels.

Simple
Authentication and Security Layer (SASL) is a framework for
authentication and data security in Internet protocols. Both RabbitMQ
and Qpid offer SASL and other pluggable authentication mechanisms beyond
simple usernames and passwords that allow for increased authentication
security. While RabbitMQ supports SASL, support in OpenStack does not
currently allow for requesting a specific SASL authentication mechanism.
RabbitMQ support in OpenStack allows for either username and password
authentication over an unencrypted connection or username and password
in conjunction with X.509 client certificates to establish the secure
SSL connection.

In addition to authentication, RabbitMQ and Qpid offer access control mechanisms
for controlling access to queues. ZeroMQ offers no such mechanisms.