Improve ch_messaging-security.xml
Use markup for passwords and indicate that it should be replaced. Add missing line in programlisting. Change IP to all-caps. Rewrap all paragraphs to avoid overlong lines. Change-Id: I13a210dcdf876312aa4803781ec6131339168a4b Closes-Bug: #1342439
This commit is contained in:
Andreas Jaeger
parent
d7b47995e6
commit
c40fe5f8e4
|
|
@ -6,11 +6,40 @@
|
|||
xml:id="messaging-security">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Messaging security</title>
|
||||
<para>This chapter discusses security hardening approaches for the three most common message queuing solutions use in OpenStack: RabbitMQ, Qpid, and ZeroMQ.</para>
|
||||
<para>
|
||||
This chapter discusses security hardening approaches for the
|
||||
three most common message queuing solutions used in OpenStack:
|
||||
RabbitMQ, Qpid, and ZeroMQ.
|
||||
</para>
|
||||
<section xml:id="messaging-security-idp37712">
|
||||
<title>Messaging transport security</title>
|
||||
<para>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.</para>
|
||||
<para>We highly recommend enabling transport-level cryptography for your message queue. Using SSL for the messaging client connections provides protection of the communications from tampering and eavesdropping in-transit to the messaging server. Below is guidance on how SSL is typically configured for the two popular messaging servers Qpid and RabbitMQ. When configuring the trusted certificate authority (CA) bundle that your messaging server uses to verify client connections, it is recommended that this be limited to only the CA used for your nodes, preferably an internally managed CA. The bundle of trusted CAs will determine which client certificates will be authorized and pass the client-server verification step of the setting up the SSL connection. Note, when installing the certificate and key files, ensure that the file permissions are restricted, for example chmod 0600, and the ownership is restricted to the messaging server daemon user to prevent unauthorized access by other processes and users on the messaging server.</para>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
We highly recommend enabling transport-level cryptography for
|
||||
your message queue. Using SSL for the messaging client
|
||||
connections provides protection of the communications from
|
||||
tampering and eavesdropping in-transit to the messaging
|
||||
server. Below is guidance on how SSL is typically configured
|
||||
for the two popular messaging servers Qpid and RabbitMQ. When
|
||||
configuring the trusted certificate authority (CA) bundle that
|
||||
your messaging server uses to verify client connections, it is
|
||||
recommended that this be limited to only the CA used for your
|
||||
nodes, preferably an internally managed CA. The bundle of
|
||||
trusted CAs will determine which client certificates will be
|
||||
authorized and pass the client-server verification step of the
|
||||
setting up the SSL connection. Note, when installing the
|
||||
certificate and key files, ensure that the file permissions
|
||||
are restricted, for example using <command>chmod 0600</command>,
|
||||
and the ownership is
|
||||
restricted to the messaging server daemon user to prevent
|
||||
unauthorized access by other processes and users on the
|
||||
messaging server.
|
||||
</para>
|
||||
<section xml:id="messaging-security-idp40512">
|
||||
<title>RabbitMQ server SSL configuration</title>
|
||||
<para>The following lines should be added to the system-wide
|
||||
|
|
@ -20,7 +49,7 @@
|
|||
<programlisting>[
|
||||
{rabbit, [
|
||||
{tcp_listeners, [] },
|
||||
{ssl_listeners, [{"<ip address or hostname of management network interface", 5671}] },
|
||||
{ssl_listeners, [{"<IP address or hostname of management network interface>", 5671}] },
|
||||
{ssl_options, [{cacertfile,"/etc/ssl/cacert.pem"},
|
||||
{certfile,"/etc/ssl/rabbit-server-cert.pem"},
|
||||
{keyfile,"/etc/ssl/rabbit-server-key.pem"},
|
||||
|
|
@ -50,14 +79,39 @@
|
|||
<itemizedlist><listitem>
|
||||
<para><link xlink:href="http://qpid.apache.org/books/0.22/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Encryption_using_SSL">Apache Qpid SSL</link></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="messaging-security-idp48960">
|
||||
<title>Queue authentication and access control</title>
|
||||
<para>RabbitMQ and Qpid offer authentication and access control mechanisms for controlling access to queues. ZeroMQ offers no such mechanisms.</para>
|
||||
<para>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 user names 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 user name and password authentication over an unencrypted connection or user name and password in conjunction with X.509 client certificates to establish the secure SSL connection.</para>
|
||||
<para>We recommend configuring X.509 client certificates on all the OpenStack service nodes for client connections to the messaging queue and where possible (currently only Qpid) perform authentication with X.509 client certificates. When using user names and passwords, accounts should be created per-service and node for finer grained auditability of access to the queue.</para>
|
||||
<para>
|
||||
RabbitMQ and Qpid offer authentication and access control
|
||||
mechanisms for controlling access to queues. ZeroMQ offers no
|
||||
such mechanisms.
|
||||
</para>
|
||||
<para>
|
||||
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 user names
|
||||
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 user name and password authentication over an
|
||||
unencrypted connection or user name and password in
|
||||
conjunction with X.509 client certificates to establish the
|
||||
secure SSL connection.
|
||||
</para>
|
||||
<para>
|
||||
We recommend configuring X.509 client certificates on all the
|
||||
OpenStack service nodes for client connections to the
|
||||
messaging queue and where possible (currently only Qpid)
|
||||
perform authentication with X.509 client certificates. When
|
||||
using user names and passwords, accounts should be created
|
||||
per-service and node for finer grained auditability of access
|
||||
to the queue.
|
||||
</para>
|
||||
<para>
|
||||
Before deployment, consider the SSL libraries that the queuing
|
||||
servers use. Qpid uses Mozilla's NSS library, whereas RabbitMQ
|
||||
|
|
@ -70,8 +124,9 @@
|
|||
<para>On the RabbitMQ server, for each OpenStack service or
|
||||
node that communicates with the message queue set up user
|
||||
accounts and privileges:</para>
|
||||
<screen><prompt>#</prompt> <userinput>rabbitmqctl add_user compute01 password</userinput>
|
||||
<screen><prompt>#</prompt> <userinput>rabbitmqctl add_user compute01 <replaceable>PASSWORD</replaceable></userinput>
|
||||
<prompt>#</prompt> <userinput>rabbitmqctl set_permissions compute01 ".*"".*"".*"</userinput></screen>
|
||||
<para>Replace <replaceable>PASSWORD</replaceable> with a suitable password.</para>
|
||||
<para>For additional configuration information see:</para>
|
||||
<itemizedlist><listitem>
|
||||
<para><link xlink:href="http://www.rabbitmq.com/access-control.html">RabbitMQ Access Control</link></para>
|
||||
|
|
@ -95,7 +150,7 @@ rabbit_use_ssl=True
|
|||
rabbit_host=
|
||||
rabbit_port=5671
|
||||
rabbit_user=compute01
|
||||
rabbit_password=password
|
||||
rabbit_password=<replaceable>PASSWORD</replaceable>
|
||||
kombu_ssl_keyfile=/etc/ssl/node-key.pem
|
||||
kombu_ssl_certfile=/etc/ssl/node-cert.pem
|
||||
kombu_ssl_ca_certs=/etc/ssl/cacert.pem</programlisting>
|
||||
|
|
@ -117,21 +172,33 @@ kombu_ssl_ca_certs=/etc/ssl/cacert.pem</programlisting>
|
|||
[DEFAULT]
|
||||
rpc_backend=nova.openstack.common.rpc.impl_qpid
|
||||
qpid_protocol=ssl
|
||||
qpid_hostname=<ip or hostname of management network interface of messaging server>
|
||||
qpid_port=5671qpid_username=compute01
|
||||
|
||||
qpid_password=password</programlisting>
|
||||
qpid_hostname=<IP or hostname of management network interface of messaging server>
|
||||
qpid_port=5671
|
||||
qpid_username=compute01
|
||||
qpid_password=<replaceable>PASSWORD</replaceable></programlisting>
|
||||
<para>Optionally, if using SASL with Qpid specify the SASL mechanisms in use by adding:</para>
|
||||
<programlisting language="ini">qpid_sasl_mechanisms=<space separated list of SASL mechanisms to use for auth></programlisting>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="messaging-security-idp68512">
|
||||
<title>Message queue process isolation and policy</title>
|
||||
<para>Each project provides a number of services which send and consume messages. Each binary which sends a message is expected to consume messages, if only replies, from the queue.</para>
|
||||
<para>Message queue service processes should be isolated from each other and other processes on a machine.</para>
|
||||
<para>
|
||||
Each project provides a number of services which send and
|
||||
consume messages. Each binary which sends a message is
|
||||
expected to consume messages, if only replies, from the queue.
|
||||
</para>
|
||||
<para>
|
||||
Message queue service processes should be isolated from each
|
||||
other and other processes on a machine.
|
||||
</para>
|
||||
<section xml:id="messaging-security-idp70304">
|
||||
<title>Namespaces</title>
|
||||
<para>Network namespaces are highly recommended for all services running on OpenStack Compute Hypervisors. This will help prevent against the bridging of network traffic between VM guests and the management network.</para>
|
||||
<para>
|
||||
Network namespaces are highly recommended for all services
|
||||
running on OpenStack Compute Hypervisors. This will help
|
||||
prevent against the bridging of network traffic between VM
|
||||
guests and the management network.
|
||||
</para>
|
||||
<para>
|
||||
When using ZeroMQ messaging, each host must run at least one
|
||||
ZeroMQ message receiver to receive messages from the network
|
||||
|
|
@ -142,12 +209,29 @@ qpid_password=password</programlisting>
|
|||
</section>
|
||||
<section xml:id="messaging-security-idp72736">
|
||||
<title>Network policy</title>
|
||||
<para>Queue servers should only accept connections from the management network. This applies to all implementations. This should be implemented through configuration of services and optionally enforced through global network policy.</para>
|
||||
<para>When using ZeroMQ messaging, each project should run a separate ZeroMQ receiver process on a port dedicated to services belonging to that project. This is equivalent to the AMQP concept of control exchanges.</para>
|
||||
<para>
|
||||
Queue servers should only accept connections from the
|
||||
management network. This applies to all
|
||||
implementations. This should be implemented through
|
||||
configuration of services and optionally enforced through
|
||||
global network policy.
|
||||
</para>
|
||||
<para>
|
||||
When using ZeroMQ messaging, each project should run a
|
||||
separate ZeroMQ receiver process on a port dedicated to
|
||||
services belonging to that project. This is equivalent to
|
||||
the AMQP concept of control exchanges.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="messaging-security-idp74736">
|
||||
<title>Mandatory access controls</title>
|
||||
<para>Use both mandatory access controls (MACs) and discretionary access controls (DACs) to restrict the configuration for processes to only those processes. This restriction prevents these processes from being isolated from other processes that run on the same machine(s).</para>
|
||||
<para>
|
||||
Use both mandatory access controls (MACs) and discretionary
|
||||
access controls (DACs) to restrict the configuration for
|
||||
processes to only those processes. This restriction prevents
|
||||
these processes from being isolated from other processes
|
||||
that run on the same machine(s).
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
|
|
|
|||
Loading…
Reference in New Issue