From 16e19d64328142d2ab29f5cc997ed1d989ecd1e0 Mon Sep 17 00:00:00 2001 From: Andreas Jaeger Date: Mon, 17 Mar 2014 21:00:39 +0100 Subject: [PATCH] plug-in needs a boost! :) Replace plugin with plug-in in text. Change-Id: I1209717446c11fd653a82840a24327a5a12e02b3 --- .../section_networking-scenarios.xml | 4 ++-- .../section_neutron-single-flat.xml | 2 +- .../ch013_node-bootstrapping.xml | 4 ++-- .../ch031_neutron-architecture.xml | 8 +++---- .../ch032_networking-best-practices.xml | 16 ++++++------- doc/security-guide/ch046_data-residency.xml | 8 +++---- doc/security-guide/ch051_vss-intro.xml | 2 +- ...module001-ch004-openstack-architecture.xml | 10 ++++---- ...odule002-ch001-networking-in-openstack.xml | 24 +++++++++---------- 9 files changed, 39 insertions(+), 39 deletions(-) diff --git a/doc/admin-guide-cloud/networking/section_networking-scenarios.xml b/doc/admin-guide-cloud/networking/section_networking-scenarios.xml index 8336df2e69..c37b58bcde 100644 --- a/doc/admin-guide-cloud/networking/section_networking-scenarios.xml +++ b/doc/admin-guide-cloud/networking/section_networking-scenarios.xml @@ -587,7 +587,7 @@ physical_interface_mappings = physnet2:eth1
ML2 - The Modular Layer 2 plugin allows OpenStack Networking + 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
Enable security group API - Since the ML2 plugin can concurrently support + Since the ML2 plug-in can concurrently support different L2 agents (or other mechanisms) with different configuration files, the actual value in the ml2_conf.ini diff --git a/doc/install-guide/section_neutron-single-flat.xml b/doc/install-guide/section_neutron-single-flat.xml index 106ed3ca18..01251ff80a 100644 --- a/doc/install-guide/section_neutron-single-flat.xml +++ b/doc/install-guide/section_neutron-single-flat.xml @@ -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. + plug-in and agent. You can modify this set up to make use of another supported plug-in and its agent. diff --git a/doc/security-guide/ch013_node-bootstrapping.xml b/doc/security-guide/ch013_node-bootstrapping.xml index 9db0e81197..6b03ec7e38 100644 --- a/doc/security-guide/ch013_node-bootstrapping.xml +++ b/doc/security-guide/ch013_node-bootstrapping.xml @@ -355,8 +355,8 @@ 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. diff --git a/doc/security-guide/ch031_neutron-architecture.xml b/doc/security-guide/ch031_neutron-architecture.xml index 179ea4de95..987838657f 100644 --- a/doc/security-guide/ch031_neutron-architecture.xml +++ b/doc/security-guide/ch031_neutron-architecture.xml @@ -1,7 +1,7 @@ Networking Architecture - 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. + 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. OpenStack Networking components encompasses the following elements: neutron server (neutron-server and neutron-*-plugin): 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. @@ -10,10 +10,10 @@ plugin agent (neutron-*-agent): 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. Optional depending on plugin. - DHCP agent (neutron-dhcp-agent): 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. + DHCP agent (neutron-dhcp-agent): 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. - l3 agent (neutron-l3-agent): Provides L3/NAT forwarding for external network access of VMs on tenant networks. Requires message queue access. Optional depending on plugin. + l3 agent (neutron-l3-agent): Provides L3/NAT forwarding for external network access of VMs on tenant networks. Requires message queue access. Optional depending on plug-in. network provider services (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. @@ -44,7 +44,7 @@ Management network 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. - Guest network 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. + Guest network 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. External network 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. diff --git a/doc/security-guide/ch032_networking-best-practices.xml b/doc/security-guide/ch032_networking-best-practices.xml index ca29ce608a..e44f86a369 100644 --- a/doc/security-guide/ch032_networking-best-practices.xml +++ b/doc/security-guide/ch032_networking-best-practices.xml @@ -47,29 +47,29 @@ Rate-limiting on a per port/network/tenant basis. - Port mirroring (via open source or third-party plugins) + Port mirroring (via open source or third-party plug-ins) - Flow analysis (via open source or third-party plugins) + Flow analysis (via open source or third-party plug-ins) - 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. + 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.
Load Balancing - 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. + 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.
Firewalls - 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. + 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. 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.
Network Services Extensions - Here is a list of known plugins provided by the open source community or by SDN companies that work with OpenStack Networking: + Here is a list of known plug-ins provided by the open source community or by SDN companies that work with OpenStack Networking: 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 - For a more detailed comparison of all features provided by plugins as of the Folsom release, see Sebastien Han's comparison. + For a more detailed comparison of all features provided by plug-ins as of the Folsom release, see Sebastien Han's comparison.
Networking Services Limitations @@ -82,7 +82,7 @@ Multi-Host DHCP-agent — 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. - No IPv6 Support for L3 agents — The neutron-l3-agent, used by many plugins to implement L3 forwarding, supports only IPv4 forwarding. + No IPv6 Support for L3 agents — The neutron-l3-agent, used by many plug-ins to implement L3 forwarding, supports only IPv4 forwarding.
diff --git a/doc/security-guide/ch046_data-residency.xml b/doc/security-guide/ch046_data-residency.xml index 0730f5ee78..02ae12c02e 100644 --- a/doc/security-guide/ch046_data-residency.xml +++ b/doc/security-guide/ch046_data-residency.xml @@ -111,14 +111,14 @@
Cinder volume data - 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. - 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. + 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. + 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. 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.
Compute instance ephemeral storage - The creation and destruction of ephemeral storage will be somewhat dependent on the chosen hypervisor and the OpenStack Compute plugin. - 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. + The creation and destruction of ephemeral storage will be somewhat dependent on the chosen hypervisor and the OpenStack Compute plug-in. + 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. 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. 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.
diff --git a/doc/security-guide/ch051_vss-intro.xml b/doc/security-guide/ch051_vss-intro.xml index 87133d6941..f26775937f 100644 --- a/doc/security-guide/ch051_vss-intro.xml +++ b/doc/security-guide/ch051_vss-intro.xml @@ -31,7 +31,7 @@ at the hypervisor level becomes paramount. The requirement for secure isolation holds true across commercial, government, and military communities. - 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, "Guide to Security for Full Virtualization Technologies". + 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, "Guide to Security for Full Virtualization Technologies".
Selection Criteria diff --git a/doc/training-guides/module001-ch004-openstack-architecture.xml b/doc/training-guides/module001-ch004-openstack-architecture.xml index f02d10ac2f..8d7d85bf8f 100644 --- a/doc/training-guides/module001-ch004-openstack-architecture.xml +++ b/doc/training-guides/module001-ch004-openstack-architecture.xml @@ -313,14 +313,14 @@ neutron-server accepts API requests and then routes - them to the appropriate Neutron plugin for action. + them to the appropriate Neutron plug-in for action. - Neutron plugins and agents perform the actual actions + 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. @@ -333,7 +333,7 @@ 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. + store networking state for particular plug-ins. Neutron will interact mainly with Nova, where it will diff --git a/doc/training-guides/module002-ch001-networking-in-openstack.xml b/doc/training-guides/module002-ch001-networking-in-openstack.xml index 031a72e1ca..2b3c5188d8 100644 --- a/doc/training-guides/module002-ch001-networking-in-openstack.xml +++ b/doc/training-guides/module002-ch001-networking-in-openstack.xml @@ -56,14 +56,14 @@ 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. - The current set of plugins include: + The current set of plug-ins include: Big Switch, Floodlight REST @@ -131,7 +131,7 @@ 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. Components of OpenStack Networking @@ -148,8 +148,8 @@ 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. If your deployment uses a controller host to run centralized @@ -164,21 +164,21 @@ plugin agent (quantum-*-agent):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. + Agent to be run depends on which plug-in you are using, + as some plug-ins do not require an agent. dhcp agent (quantum-dhcp-agent):Provides DHCP services to tenant networks. This agent is the same - across all plugins. + across all plug-ins. l3 agent (quantum-l3-agent):Provides L3/NAT forwarding to provide external network access for VMs on tenant networks. This agent is the same across all - plugins. + plug-ins. These agents interact with the main quantum-server process @@ -246,7 +246,7 @@ Data network:Used for VM data communication within the cloud deployment. The IP addressing requirements of this network depend - on the OpenStack Networking plugin in use. + on the OpenStack Networking plug-in in use. External