aceec15371
Better follow conventions, especially: * remove Latinism like via and i.e. * use variable lists * Add missing <filename> * wrap long lines Change-Id: I2a537df78ddf4fbeb127b058bf05caaf42441d5f
90 lines
3.8 KiB
XML
90 lines
3.8 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
xmlns="http://docbook.org/ns/docbook"
|
|
version="5.0"
|
|
xml:id="ch033_securing-neutron-services">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Securing OpenStack Networking services</title>
|
|
<para>
|
|
To secure OpenStack Networking, you must understand how the
|
|
workflow process for tenant instance creation needs to be mapped
|
|
to security domains.</para>
|
|
<para>
|
|
There are four main services that interact with OpenStack
|
|
Networking. In a typical OpenStack deployment these services map
|
|
to the following security domains:</para>
|
|
<itemizedlist><listitem>
|
|
<para>OpenStack dashboard: Public and management</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>OpenStack Identity: Management</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>OpenStack compute node: Management and guest</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>OpenStack network node: Management, guest, and possibly
|
|
public depending upon neutron-plugin in use.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>SDN services node: Management, guest and possibly
|
|
public depending upon product used.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>
|
|
<inlinemediaobject>
|
|
<imageobject role="html">
|
|
<imagedata contentdepth="454" contentwidth="682"
|
|
fileref="static/1aa-logical-neutron-flow.png"
|
|
format="PNG" scalefit="1"/>
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%"
|
|
fileref="static/1aa-logical-neutron-flow.png"
|
|
format="PNG" scalefit="1" width="100%"/>
|
|
</imageobject>
|
|
</inlinemediaobject>
|
|
</para>
|
|
<para>To isolate sensitive data communication between the
|
|
OpenStack Networking services and other OpenStack core
|
|
services, configure these communication channels to only allow
|
|
communication over an isolated management network.</para>
|
|
<section xml:id="ch033_securing-neutron-services-idp55312">
|
|
<title>OpenStack Networking service configuration</title>
|
|
<section xml:id="ch033_securing-neutron-services-idp56016">
|
|
<title>Restrict bind address of the API server: neutron-server</title>
|
|
<para>
|
|
To restrict the interface or IP address on which the
|
|
OpenStack Networking API service binds a network socket for
|
|
incoming client connections, specify the bind_host and
|
|
bind_port in the neutron.conf file as shown:</para>
|
|
<programlisting language="ini">
|
|
# Address to bind the API server
|
|
bind_host = <replaceable>IP ADDRESS OF SERVER</replaceable>
|
|
|
|
# Port the bind the API server to
|
|
bind_port = 9696</programlisting>
|
|
</section>
|
|
<section xml:id="ch033_securing-neutron-services-idp58320">
|
|
<title>Restrict DB and RPC communication of the OpenStack
|
|
Networking services</title>
|
|
<para>
|
|
Various components of the OpenStack Networking services use
|
|
either the messaging queue or database connections to
|
|
communicate with other components in OpenStack
|
|
Networking.</para>
|
|
<para>
|
|
It is recommended that you follow the guidelines provided in
|
|
the Database Authentication and Access Control chapter in
|
|
the Database section for all components that require direct
|
|
DB connections.</para>
|
|
<para>
|
|
It is recommended that you follow the guidelines provided in
|
|
the Queue Authentication and Access Control chapter in the
|
|
Messaging section for all components that require RPC
|
|
communication.</para>
|
|
</section>
|
|
</section>
|
|
</chapter>
|