openstack/nova
Code Issues Proposed changes

Typo fix: remove multiple whitespace

Browse Source 
Remove multiple whitespace character from
doc/networking.rst file.

TrivialFix

Change-Id: I3e6a1543a3a0d8b001a158fda0e715f6098dab02
This commit is contained in:
Alex Szarka 2016-07-07 16:40:13 +02:00
parent d3c1ce2635
commit 5af5d051a9
1 changed files with 29 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
plugins/xenserver/doc/networking.rst
View File

@ -2,10 +2,10 @@ Multi Tenancy Networking Protections in XenServer
================================================= =================================================
The purpose of the vif_rules script is to allow multi-tenancy on a XenServer The purpose of the vif_rules script is to allow multi-tenancy on a XenServer
host. In a multi-tenant cloud environment a host machine needs to be able to host. In a multi-tenant cloud environment a host machine needs to be able to
enforce network isolation amongst guest instances, at both layer two and layer enforce network isolation amongst guest instances, at both layer two and layer
three. The rules prevent guests from taking and using unauthorized IP addresses, three. The rules prevent guests from taking and using unauthorized IP addresses,
sniffing other guests traffic, and prevents ARP poisoning attacks. This current sniffing other guests traffic, and prevents ARP poisoning attacks. This current
revision only supports IPv4, but will support IPv6 in the future. revision only supports IPv4, but will support IPv6 in the future.
Kernel Requirements Kernel Requirements
@ -22,43 +22,43 @@ the proper version of XenServer to recompile the dom0 kernel.
XenServer Requirements (32-bit dom0) XenServer Requirements (32-bit dom0)
==================================== ====================================
- arptables 32-bit rpm - arptables 32-bit rpm
- ebtables 32-bit rpm - ebtables 32-bit rpm
- python-simplejson - python-simplejson
XenServer Environment Specific Notes XenServer Environment Specific Notes
==================================== ====================================
- XenServer 5.5 U1 based on the 2.6.18 kernel didn't include physdev module - XenServer 5.5 U1 based on the 2.6.18 kernel didn't include physdev module
support. Support for this had to be recompiled into the kernel. support. Support for this had to be recompiled into the kernel.
- XenServer 5.6 based on the 2.6.27 kernel didn't include physdev, ebtables, or - XenServer 5.6 based on the 2.6.27 kernel didn't include physdev, ebtables, or
arptables. arptables.
- XenServer 5.6 FP1 didn't include physdev, ebtables, or arptables but they do - XenServer 5.6 FP1 didn't include physdev, ebtables, or arptables but they do
have a Cloud Supplemental pack available to partners which swaps out the have a Cloud Supplemental pack available to partners which swaps out the
kernels for kernels that support the networking rules. kernels for kernels that support the networking rules.
How it works - tl;dr How it works - tl;dr
==================== ====================
iptables, ebtables, and arptables drop rules are applied to all forward chains iptables, ebtables, and arptables drop rules are applied to all forward chains
on the host. These are applied at boot time with an init script. They ensure on the host. These are applied at boot time with an init script. They ensure
all forwarded packets are dropped by default. Allow rules are then applied to all forwarded packets are dropped by default. Allow rules are then applied to
the instances to ensure they have permission to talk on the internet. the instances to ensure they have permission to talk on the internet.
How it works - Long How it works - Long
=================== ===================
Any time an underprivileged domain or domU is started or stopped, it Any time an underprivileged domain or domU is started or stopped, it
gets a unique domain id (dom_id). This dom_id is utilized in a number gets a unique domain id (dom_id). This dom_id is utilized in a number
of places, one of which is that it is assigned to the virtual of places, one of which is that it is assigned to the virtual
interface (vif). The vifs are attached to the bridge that is attached interface (vif). The vifs are attached to the bridge that is attached
to the physical network. For instance, if you had a public bridge to the physical network. For instance, if you had a public bridge
attached to eth0 and your domain id was 5, your vif would be vif5.0. attached to eth0 and your domain id was 5, your vif would be vif5.0.
The networking rules are applied to the VIF directly so they apply at the lowest The networking rules are applied to the VIF directly so they apply at the lowest
level of the networking stack. Because the VIF changes along with the domain id level of the networking stack. Because the VIF changes along with the domain id
on any start, stop, or reboot of the instance, the rules need to be removed and on any start, stop, or reboot of the instance, the rules need to be removed and
re-added any time that occurs. re-added any time that occurs.
Because the dom_id can change often, the vif_rules script is hooked into the Because the dom_id can change often, the vif_rules script is hooked into the
/etc/xensource/scripts/vif script that gets called anytime an instance is /etc/xensource/scripts/vif script that gets called anytime an instance is
@ -66,11 +66,11 @@ started, or stopped, which includes pauses and resumes.
Examples of the rules ran for the host on boot: Examples of the rules ran for the host on boot:
iptables -P FORWARD DROP iptables -P FORWARD DROP
iptables -A FORWARD -m physdev --physdev-in eth0 -j ACCEPT iptables -A FORWARD -m physdev --physdev-in eth0 -j ACCEPT
ebtables -P FORWARD DROP ebtables -P FORWARD DROP
ebtables -A FORWARD -o eth0 -j ACCEPT ebtables -A FORWARD -o eth0 -j ACCEPT
arptables -P FORWARD DROP arptables -P FORWARD DROP
arptables -A FORWARD --opcode Request --in-interface eth0 -j ACCEPT arptables -A FORWARD --opcode Request --in-interface eth0 -j ACCEPT
arptables -A FORWARD --opcode Reply --in-interface eth0 -j ACCEPT arptables -A FORWARD --opcode Reply --in-interface eth0 -j ACCEPT
@ -82,37 +82,37 @@ arptables -A FORWARD --opcode Request --in-interface "vif1.0" \
arptables -A FORWARD --opcode Reply --in-interface "vif1.0" \ arptables -A FORWARD --opcode Reply --in-interface "vif1.0" \
--source-ip 10.1.135.22 --source-mac 9e:6e:cc:19:7f:fe -j ACCEPT --source-ip 10.1.135.22 --source-mac 9e:6e:cc:19:7f:fe -j ACCEPT
ebtables -A FORWARD -p 0806 -o vif1.0 --arp-ip-dst 10.1.135.22 -j ACCEPT ebtables -A FORWARD -p 0806 -o vif1.0 --arp-ip-dst 10.1.135.22 -j ACCEPT
ebtables -A FORWARD -p 0800 -o vif1.0 --ip-dst 10.1.135.22 -j ACCEPT ebtables -A FORWARD -p 0800 -o vif1.0 --ip-dst 10.1.135.22 -j ACCEPT
ebtables -I FORWARD 1 -s ! 9e:6e:cc:19:7f:fe -i vif1.0 -j DROP ebtables -I FORWARD 1 -s ! 9e:6e:cc:19:7f:fe -i vif1.0 -j DROP
Typically when you see a vif, it'll look like Typically when you see a vif, it'll look like
vif<domain id>.<network bridge>. vif2.1 for example would be domain 2 on the vif<domain id>.<network bridge>. vif2.1 for example would be domain 2 on the
second interface. second interface.
The vif_rules.py script needs to pull information about the IPs and MAC The vif_rules.py script needs to pull information about the IPs and MAC
addresses assigned to the instance. The current implementation assumes that addresses assigned to the instance. The current implementation assumes that
information is put into the VM Record into the xenstore-data key in a JSON information is put into the VM Record into the xenstore-data key in a JSON
string. The vif_rules.py script reads out of the JSON string to determine the string. The vif_rules.py script reads out of the JSON string to determine the
IPs, and MAC addresses to protect. IPs, and MAC addresses to protect.
An example format is given below: An example format is given below:
# xe vm-param-get uuid=<uuid> param-name=xenstore-data # xe vm-param-get uuid=<uuid> param-name=xenstore-data
xenstore-data (MRW): xenstore-data (MRW):
vm-data/networking/4040fa7292e4: vm-data/networking/4040fa7292e4:
{"label": "public", {"label": "public",
"ips": [{"netmask":"255.255.255.0", "ips": [{"netmask":"255.255.255.0",
"enabled":"1", "enabled":"1",
"ip":"173.200.100.10"}], "ip":"173.200.100.10"}],
"mac":"40:40:fa:72:92:e4", "mac":"40:40:fa:72:92:e4",
"gateway":"173.200.100.1", "gateway":"173.200.100.1",
"vm_id":"123456", "vm_id":"123456",
"dns":["72.3.128.240","72.3.128.241"]}; "dns":["72.3.128.240","72.3.128.241"]};
vm-data/networking/40402321c9b8: vm-data/networking/40402321c9b8:
{"label":"private", {"label":"private",
"ips":[{"netmask":"255.255.224.0", "ips":[{"netmask":"255.255.224.0",
"enabled":"1", "enabled":"1",
"ip":"10.177.10.10"}], "ip":"10.177.10.10"}],
"routes":[{"route":"10.176.0.0", "routes":[{"route":"10.176.0.0",
"netmask":"255.248.0.0", "netmask":"255.248.0.0",
@ -122,10 +122,10 @@ vm-data/networking/40402321c9b8:
"gateway":"10.177.10.1"}], "gateway":"10.177.10.1"}],
"mac":"40:40:23:21:c9:b8"} "mac":"40:40:23:21:c9:b8"}
The key is used for two purposes. First, the vif_rules.py script The key is used for two purposes. First, the vif_rules.py script
reads from it to apply the rules needed after parsing the JSON. reads from it to apply the rules needed after parsing the JSON.
Second, because it is put into the xenstore-data field, the xenstore Second, because it is put into the xenstore-data field, the xenstore
is populated with this data on boot. This allows a guest agent the is populated with this data on boot. This allows a guest agent the
ability to read out data about the instance and apply configurations ability to read out data about the instance and apply configurations
as needed. as needed.
@ -135,7 +135,7 @@ Installation
- Copy host-rules into /etc/init.d/ and make sure to chmod +x host-rules. - Copy host-rules into /etc/init.d/ and make sure to chmod +x host-rules.
- Run 'chkconfig host-rules on' to add the init script to start up. - Run 'chkconfig host-rules on' to add the init script to start up.
- Copy vif_rules.py into /etc/xensource/scripts - Copy vif_rules.py into /etc/xensource/scripts
- Patch /etc/xensource/scripts/vif using the supplied patch file. It may vary - Patch /etc/xensource/scripts/vif using the supplied patch file. It may vary
for different versions of XenServer but it should be pretty self explanatory. for different versions of XenServer but it should be pretty self explanatory.
It calls the vif_rules.py script on domain creation and tear down. It calls the vif_rules.py script on domain creation and tear down.
- Run '/etc/init.d/host-rules start' to start up the host based rules. - Run '/etc/init.d/host-rules start' to start up the host based rules.
@ -143,4 +143,3 @@ Installation
JSON is in place. JSON is in place.
- You can check to see if the rules are in place with: iptables --list, - You can check to see if the rules are in place with: iptables --list,
arptables --list, or ebtables --list arptables --list, or ebtables --list