plug-in needs a boost! :)
Replace plugin with plug-in in text. Change-Id: I1209717446c11fd653a82840a24327a5a12e02b3
This commit is contained in:
Andreas Jaeger
parent
f9b28d3403
commit
16e19d6432
@ -587,7 +587,7 @@ physical_interface_mappings = physnet2:eth1</programlisting></para>
|
||||
</section>
|
||||
<section xml:id="ml2_scenarios">
|
||||
<title>ML2</title>
|
||||
<para>The Modular Layer 2 plugin allows OpenStack Networking
|
||||
<para>The Modular Layer 2 plug-in allows OpenStack Networking
|
||||
to simultaneously utilize the variety of layer 2 networking
|
||||
technologies found in complex real-world data centers.
|
||||
It currently includes drivers for the local, flat, VLAN,
|
||||
@ -675,7 +675,7 @@ l2_population = True</programlisting></para>
|
||||
</section>
|
||||
<section xml:id="ml2_l2_security_group">
|
||||
<title>Enable security group API</title>
|
||||
<para>Since the ML2 plugin can concurrently support
|
||||
<para>Since the ML2 plug-in can concurrently support
|
||||
different L2 agents (or other mechanisms) with different
|
||||
configuration files, the actual <option>firewall_driver
|
||||
</option> value in the <filename>ml2_conf.ini</filename>
|
||||
|
||||
@ -11,7 +11,7 @@
|
||||
nodes should have one interface for management traffic and one
|
||||
or more interfaces for traffic to and from VMs. The management
|
||||
network is 100.1.1.0/24 with controller node at 100.1.1.2. The example uses the Open vSwitch
|
||||
plugin and agent.</para>
|
||||
plug-in and agent.</para>
|
||||
<note>
|
||||
<para>You can modify this set up to make use of another
|
||||
supported plug-in and its agent.</para>
|
||||
|
||||
@ -355,8 +355,8 @@
|
||||
<para>Network intrusion detection tools complement the
|
||||
host-based tools. OpenStack doesn't have a specific network
|
||||
IDS built-in, but OpenStack's networking component, Neutron,
|
||||
provides a plugin mechanism to enable different technologies
|
||||
via the Neutron API. This plugin architecture will allow
|
||||
provides a plug-in mechanism to enable different technologies
|
||||
via the Neutron API. This plug-in architecture will allow
|
||||
tenants to develop API extensions to insert and configure
|
||||
their own advanced networking services like a firewall, an
|
||||
intrusion detection system, or a VPN between the VMs.</para>
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
<?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" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch031_neutron-architecture"><?dbhtml stop-chunking?>
|
||||
<title>Networking Architecture</title>
|
||||
<para>OpenStack Networking is a standalone service that often involves deploying several processes across a number of nodes. These processes interact with each other and with other OpenStack services. The main process of the OpenStack Networking service is neutron-server, a Python daemon that exposes the OpenStack Networking API and passes tenant requests to a suite of plugins for additional processing.</para>
|
||||
<para>OpenStack Networking is a standalone service that often involves deploying several processes across a number of nodes. These processes interact with each other and with other OpenStack services. The main process of the OpenStack Networking service is neutron-server, a Python daemon that exposes the OpenStack Networking API and passes tenant requests to a suite of plug-ins for additional processing.</para>
|
||||
<para>OpenStack Networking components encompasses the following elements:</para>
|
||||
<itemizedlist><listitem>
|
||||
<para><emphasis role="bold">neutron server</emphasis> (<literal>neutron-server</literal> and <literal>neutron-*-plugin</literal>): This service runs on the network node to service the Networking API and its extensions. It also enforces the network model and IP addressing of each port. The neutron-server and plugin agents require access to a database for persistent storage and access to a message queue for inter-communication.</para>
|
||||
@ -10,10 +10,10 @@
|
||||
<para><emphasis role="bold">plugin agent</emphasis> (<literal>neutron-*-agent</literal>): Runs on each compute node to manage local virtual switch (vswitch) configuration. The agents to be run will depend on which plugin you are using. This service requires message queue access. <emphasis>Optional depending on plugin.</emphasis></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">DHCP agent</emphasis> (<literal>neutron-dhcp-agent</literal>): Provides DHCP services to tenant networks. This agent is the same across all plugins and is responsible for maintaining DHCP configuration. The neutron-dhcp-agent requires message queue access.</para>
|
||||
<para><emphasis role="bold">DHCP agent</emphasis> (<literal>neutron-dhcp-agent</literal>): Provides DHCP services to tenant networks. This agent is the same across all plug-ins and is responsible for maintaining DHCP configuration. The neutron-dhcp-agent requires message queue access.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">l3 agent</emphasis> (<literal>neutron-l3-agent</literal>): Provides L3/NAT forwarding for external network access of VMs on tenant networks. Requires message queue access. <emphasis>Optional depending on plugin.</emphasis></para>
|
||||
<para><emphasis role="bold">l3 agent</emphasis> (<literal>neutron-l3-agent</literal>): Provides L3/NAT forwarding for external network access of VMs on tenant networks. Requires message queue access. <emphasis>Optional depending on plug-in.</emphasis></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">network provider services</emphasis> (SDN server/services). Provide additional networking services that are provided to tenant networks. These SDN services may interact with the neutron-server, neutron-plugin, and/or plugin-agents via REST APIs or other communication channels.</para>
|
||||
@ -44,7 +44,7 @@
|
||||
<para><emphasis role="bold">Management network</emphasis> Used for internal communication between OpenStack Components. The IP addresses on this network should be reachable only within the data center and is considered the Management Security Domain.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Guest network</emphasis> Used for VM data communication within the cloud deployment. The IP addressing requirements of this network depend on the OpenStack Networking plugin in use and the network configuration choices of the virtual networks made by the tenant. This network is considered the Guest Security Domain.</para>
|
||||
<para><emphasis role="bold">Guest network</emphasis> Used for VM data communication within the cloud deployment. The IP addressing requirements of this network depend on the OpenStack Networking plug-in in use and the network configuration choices of the virtual networks made by the tenant. This network is considered the Guest Security Domain.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">External network</emphasis> Used to provide VMs with Internet access in some deployment scenarios. The IP addresses on this network should be reachable by anyone on the Internet and is considered to be in the Public Security Domain.</para>
|
||||
|
||||
@ -47,29 +47,29 @@
|
||||
<para>Rate-limiting on a per port/network/tenant basis.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Port mirroring (via open source or third-party plugins)</para>
|
||||
<para>Port mirroring (via open source or third-party plug-ins)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Flow analysis (via open source or third-party plugins)</para>
|
||||
<para>Flow analysis (via open source or third-party plug-ins)</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Tenant traffic port mirroring or Network Flow monitoring is currently not an exposed feature in OpenStack Networking. There are third-party plugin extensions that do provide Port Mirroring on a per port/network/tenant basis. If Open vSwitch is used on the networking hypervisor, it is possible to enable sFlow and port mirroring, however it will require some operational effort to implement.</para>
|
||||
<para>Tenant traffic port mirroring or Network Flow monitoring is currently not an exposed feature in OpenStack Networking. There are third-party plug-in extensions that do provide Port Mirroring on a per port/network/tenant basis. If Open vSwitch is used on the networking hypervisor, it is possible to enable sFlow and port mirroring, however it will require some operational effort to implement.</para>
|
||||
</section>
|
||||
<section xml:id="ch032_networking-best-practices-idp69408">
|
||||
<title>Load Balancing</title>
|
||||
<para>An experimental feature in the Grizzly release of OpenStack Networking is Load-Balancer-as-a-service (LBaaS). The LBaaS API gives early adopters and vendors a chance to build implementations of the technology. The reference implementation however, is still experimental and should likely not be run in a production environment. The current reference implementation is based on HA-Proxy. There are third-party plugins in development for extensions in OpenStack Networking to provide extensive L4-L7 functionality for virtual interface ports.</para>
|
||||
<para>An experimental feature in the Grizzly release of OpenStack Networking is Load-Balancer-as-a-service (LBaaS). The LBaaS API gives early adopters and vendors a chance to build implementations of the technology. The reference implementation however, is still experimental and should likely not be run in a production environment. The current reference implementation is based on HA-Proxy. There are third-party plug-ins in development for extensions in OpenStack Networking to provide extensive L4-L7 functionality for virtual interface ports.</para>
|
||||
</section>
|
||||
<section xml:id="ch032_networking-best-practices-idp71664">
|
||||
<title>Firewalls</title>
|
||||
<para>FW-as-a-Service (FWaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. FWaaS will address the need to manage and leverage the rich set of security features provided by typical firewall products which are typically far more comprehensive than what is currently provided by security groups. There are third-party plugins in development for extensions in OpenStack Networking to support this.</para>
|
||||
<para>FW-as-a-Service (FWaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. FWaaS will address the need to manage and leverage the rich set of security features provided by typical firewall products which are typically far more comprehensive than what is currently provided by security groups. There are third-party plug-ins in development for extensions in OpenStack Networking to support this.</para>
|
||||
<para>It is critical during the design of an OpenStack Networking infrastructure to understand the current features and limitations of network services that are available. Understanding where the boundaries of your virtual and physical networks will help you add the required security controls in your environment.</para>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="ch032_networking-best-practices-idp74544">
|
||||
<title>Network Services Extensions</title>
|
||||
<para>Here is a list of known plugins provided by the open source community or by SDN companies that work with OpenStack Networking:</para>
|
||||
<para>Here is a list of known plug-ins provided by the open source community or by SDN companies that work with OpenStack Networking:</para>
|
||||
<para>Big Switch Controller Plugin, Brocade Neutron Plugin Brocade Neutron Plugin, Cisco UCS/Nexus Plugin, Cloudbase Hyper-V Plugin, Extreme Networks Plugin, Juniper Networks Neutron Plugin, Linux Bridge Plugin, Mellanox Neutron Plugin, MidoNet Plugin, NEC OpenFlow Plugin, Open vSwitch Plugin, PLUMgrid Plugin, Ruijie Networks Plugin, Ryu OpenFlow Controller Plugin, VMware NSX plugin</para>
|
||||
<para>For a more detailed comparison of all features provided by plugins as of the Folsom release, see <link xlink:href="http://www.sebastien-han.fr/blog/2012/09/28/quantum-plugin-comparison/">Sebastien Han's comparison</link>.</para>
|
||||
<para>For a more detailed comparison of all features provided by plug-ins as of the Folsom release, see <link xlink:href="http://www.sebastien-han.fr/blog/2012/09/28/quantum-plugin-comparison/">Sebastien Han's comparison</link>.</para>
|
||||
</section>
|
||||
<section xml:id="ch032_networking-best-practices-idp78032">
|
||||
<title>Networking Services Limitations</title>
|
||||
@ -82,7 +82,7 @@
|
||||
<para><emphasis role="bold">Multi-Host DHCP-agent</emphasis> — OpenStack Networking supports multiple l3-agent and dhcp-agents with load balancing. However, tight coupling of the location of the virtual machine is not supported.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">No IPv6 Support for L3 agents</emphasis> — The neutron-l3-agent, used by many plugins to implement L3 forwarding, supports only IPv4 forwarding.</para>
|
||||
<para><emphasis role="bold">No IPv6 Support for L3 agents</emphasis> — The neutron-l3-agent, used by many plug-ins to implement L3 forwarding, supports only IPv4 forwarding.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
@ -111,14 +111,14 @@
|
||||
</section>
|
||||
<section xml:id="ch046_data-residency-idp78448">
|
||||
<title>Cinder volume data</title>
|
||||
<para>Plugins to OpenStack Block Storage will store data in a variety of ways. Many plugins are specific to a vendor or technology, whereas others are more DIY solutions around filesystems such as LVM or ZFS. Methods to securely destroy data will vary from one plugin to another, from one vendor's solution to another, and from one filesystem to another.</para>
|
||||
<para>Some backends such as ZFS will support copy-on-write to prevent data exposure. In these cases, reads from unwritten blocks will always return zero. Other backends such as LVM may not natively support this, thus the Cinder plugin takes the responsibility to override previously written blocks before handing them to users. It is important to review what assurances your chosen volume backend provides and to see what mediations may be available for those assurances not provided.</para>
|
||||
<para>Plugins to OpenStack Block Storage will store data in a variety of ways. Many plug-ins are specific to a vendor or technology, whereas others are more DIY solutions around filesystems such as LVM or ZFS. Methods to securely destroy data will vary from one plugin to another, from one vendor's solution to another, and from one filesystem to another.</para>
|
||||
<para>Some backends such as ZFS will support copy-on-write to prevent data exposure. In these cases, reads from unwritten blocks will always return zero. Other backends such as LVM may not natively support this, thus the Block Storage plug-in takes the responsibility to override previously written blocks before handing them to users. It is important to review what assurances your chosen volume backend provides and to see what mediations may be available for those assurances not provided.</para>
|
||||
<para>Finally, while not a feature of OpenStack, vendors and implementors may choose to add or support encryption of volumes. In this case, destruction of data is as simple as throwing away the key.</para>
|
||||
</section>
|
||||
<section xml:id="ch046_data-residency-idp81664">
|
||||
<title>Compute instance ephemeral storage</title>
|
||||
<para>The creation and destruction of ephemeral storage will be somewhat dependent on the chosen hypervisor and the OpenStack Compute plugin.</para>
|
||||
<para>The libvirt plugin for compute may maintain ephemeral storage directly on a filesystem, or in LVM. Filesystem storage generally will not overwrite data when it is removed, although there is a guarantee that dirty extents are not provisioned to users.</para>
|
||||
<para>The creation and destruction of ephemeral storage will be somewhat dependent on the chosen hypervisor and the OpenStack Compute plug-in.</para>
|
||||
<para>The libvirt plug-in for compute may maintain ephemeral storage directly on a filesystem, or in LVM. Filesystem storage generally will not overwrite data when it is removed, although there is a guarantee that dirty extents are not provisioned to users.</para>
|
||||
<para>When using LVM backed ephemeral storage, which is block-based, it is necessary that the OpenStack Compute software securely erases blocks to prevent information disclosure. There have in the past been information disclosure vulnerabilities related to improperly erased ephemeral block storage devices.</para>
|
||||
<para>Filesystem storage is a more secure solution for ephemeral block storage devices than LVM as dirty extents cannot be provisioned to users. However, it is important to be mindful that user data is not destroyed, so it is suggested to encrypt the backing filesystem.</para>
|
||||
</section>
|
||||
|
||||
@ -31,7 +31,7 @@
|
||||
at the hypervisor level becomes paramount. The requirement for
|
||||
secure isolation holds true across commercial, government, and
|
||||
military communities.</para>
|
||||
<para>Within the framework of OpenStack you can choose from any number of hypervisor platforms and corresponding OpenStack plugins to optimize your cloud environment. In the context of the OpenStack Security guide, we will be highlighting hypervisor selection considerations as they pertain to feature sets that are critical to security. However, these considerations are not meant to be an exhaustive investigation into the pros and cons of particular hypervisors. NIST provides additional guidance in Special Publication 800-125, "<emphasis>Guide to Security for Full Virtualization Technologies</emphasis>".</para>
|
||||
<para>Within the framework of OpenStack you can choose from any number of hypervisor platforms and corresponding OpenStack plug-ins to optimize your cloud environment. In the context of the OpenStack Security guide, we will be highlighting hypervisor selection considerations as they pertain to feature sets that are critical to security. However, these considerations are not meant to be an exhaustive investigation into the pros and cons of particular hypervisors. NIST provides additional guidance in Special Publication 800-125, "<emphasis>Guide to Security for Full Virtualization Technologies</emphasis>".</para>
|
||||
</section>
|
||||
<section xml:id="ch051_vss-intro-idp242144">
|
||||
<title>Selection Criteria</title>
|
||||
|
||||
@ -313,14 +313,14 @@
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>neutron-server accepts API requests and then routes
|
||||
them to the appropriate Neutron plugin for action.</para>
|
||||
them to the appropriate Neutron plug-in for action.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Neutron plugins and agents perform the actual actions
|
||||
<para>Neutron plug-ins and agents perform the actual actions
|
||||
such as plugging and unplugging ports, creating networks
|
||||
or subnets and IP addressing. These plugins and agents
|
||||
or subnets and IP addressing. These plug-ins and agents
|
||||
differ depending on the vendor and technologies used in
|
||||
the particular cloud. Neutron ships with plugins and
|
||||
the particular cloud. Neutron ships with plug-ins and
|
||||
agents for: Cisco virtual and physical switches, NEC
|
||||
OpenFlow products, Open vSwitch, Linux bridging, the Ryu
|
||||
Network Operating System, and VMware NSX.</para>
|
||||
@ -333,7 +333,7 @@
|
||||
<para>Most Neutron installations will also make use of a
|
||||
messaging queue to route information between the
|
||||
neutron-server and various agents as well as a database to
|
||||
store networking state for particular plugins.</para>
|
||||
store networking state for particular plug-ins.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Neutron will interact mainly with Nova, where it will
|
||||
|
||||
@ -56,14 +56,14 @@
|
||||
<para>The original OpenStack Compute network implementation
|
||||
assumed a very basic model of performing all isolation through
|
||||
Linux VLANs and IP tables. OpenStack Networking introduces the
|
||||
concept of a plugin, which is a pluggable back-end
|
||||
implementation of the OpenStack Networking API. A plugin can
|
||||
concept of a plug-in, which is a pluggable back-end
|
||||
implementation of the OpenStack Networking API. A plug-in can
|
||||
use a variety of technologies to implement the logical API
|
||||
requests. Some OpenStack Networking plugins might use basic
|
||||
requests. Some OpenStack Networking plug-ins might use basic
|
||||
Linux VLANs and IP tables, while others might use more
|
||||
advanced technologies, such as L2-in-L3 tunneling or OpenFlow,
|
||||
to provide similar benefits.</para>
|
||||
<para>The current set of plugins include:</para>
|
||||
<para>The current set of plug-ins include:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Big Switch, Floodlight REST
|
||||
@ -131,7 +131,7 @@
|
||||
</itemizedlist>
|
||||
<para>Plugins can have different properties in terms of hardware
|
||||
requirements, features, performance, scale, operator tools,
|
||||
etc. Supporting many plugins enables the cloud administrator
|
||||
etc. Supporting many plug-ins enables the cloud administrator
|
||||
to weigh different options and decide which networking
|
||||
technology is right for the deployment.</para>
|
||||
<para>Components of OpenStack Networking</para>
|
||||
@ -148,8 +148,8 @@
|
||||
<para>The main process of the OpenStack Networking server is
|
||||
quantum-server, which is a Python daemon that exposes the
|
||||
OpenStack Networking API and passes user requests to the
|
||||
configured OpenStack Networking plugin for additional
|
||||
processing. Typically, the plugin requires access to a
|
||||
configured OpenStack Networking plug-in for additional
|
||||
processing. Typically, the plug-in requires access to a
|
||||
database for persistent storage, similar to other OpenStack
|
||||
services.</para>
|
||||
<para>If your deployment uses a controller host to run centralized
|
||||
@ -164,21 +164,21 @@
|
||||
<para><emphasis role="bold">plugin agent
|
||||
(quantum-*-agent):</emphasis>Runs on each
|
||||
hypervisor to perform local vswitch configuration.
|
||||
Agent to be run depends on which plugin you are using,
|
||||
as some plugins do not require an agent.</para>
|
||||
Agent to be run depends on which plug-in you are using,
|
||||
as some plug-ins do not require an agent.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">dhcp agent
|
||||
(quantum-dhcp-agent):</emphasis>Provides DHCP
|
||||
services to tenant networks. This agent is the same
|
||||
across all plugins.</para>
|
||||
across all plug-ins.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">l3 agent
|
||||
(quantum-l3-agent):</emphasis>Provides L3/NAT
|
||||
forwarding to provide external network access for VMs
|
||||
on tenant networks. This agent is the same across all
|
||||
plugins.</para>
|
||||
plug-ins.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>These agents interact with the main quantum-server process
|
||||
@ -246,7 +246,7 @@
|
||||
<para><emphasis role="bold">Data network:</emphasis>Used
|
||||
for VM data communication within the cloud deployment.
|
||||
The IP addressing requirements of this network depend
|
||||
on the OpenStack Networking plugin in use.</para>
|
||||
on the OpenStack Networking plug-in in use.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">External
|
||||
|
||||
Loading…
Reference in New Issue
Block a user