Bases: object
Apply instance filter.
Once this method returns, the instance should be firewalled appropriately. This method should as far as possible be a no-op. It’s vastly preferred to get everything set up in prepare_instance_filter.
Check nova-instance-instance-xxx exists
Prepare filters for the instance.
At this point, the instance isn’t running yet.
Refresh common rules for all hosts/instances from data store.
Gets called when a rule has been added to or removed from the list of rules (via admin api).
Refresh security group members from data store
Gets called when an instance gets added to or removed from the security group.
Refresh security group rules from data store
Gets called when a rule has been added to or removed from the security group.
Create rules to block spoofing and allow dhcp.
This gets called when spawning an instance, before :method:`prepare_instance_filter`.
Stop filtering instance
Bases: nova.virt.libvirt.firewall.FirewallDriver
No-op. Everything is done in prepare_instance_filter
Check nova-instance-instance-xxx exists
See class:FirewallDriver: docs.
Set up provider rules and basic NWFilter.
Bases: nova.virt.libvirt.firewall.FirewallDriver
This class implements a network filtering mechanism versatile enough for EC2 style Security Group filtering by leveraging libvirt’s nwfilter.
First, all instances get a filter (“nova-base-filter”) applied. This filter provides some basic security such as protection against MAC spoofing, IP spoofing, and ARP spoofing.
This filter drops all incoming ipv4 and ipv6 connections. Outgoing connections are never blocked.
Second, every security group maps to a nwfilter filter(*). NWFilters can be updated at runtime and changes are applied immediately, so changes to security groups can be applied at runtime (as mandated by the spec).
Security group rules are named “nova-secgroup-<id>” where <id> is the internal id of the security group. They’re applied only on hosts that have instances in the security group in question.
Updates to security groups are done by updating the data model (in response to API calls) followed by a request sent to all the nodes with instances in the security group to refresh the security group.
Each instance has its own NWFilter, which references the above mentioned security group NWFilters. This was done because interfaces can only reference one filter while filters can reference multiple other filters. This has the added benefit of actually being able to add and remove security groups from an instance at run time. This functionality is not exposed anywhere, though.
Outstanding questions:
The name is unique, so would there be any good reason to sync the uuid across the nodes (by assigning it from the datamodel)?
No-op. Everything is done in prepare_instance_filter
Check nova-instance-instance-xxx exists
The standard allow-dhcp-server filter is an <ip> one, so it uses ebtables to allow traffic through. Without a corresponding rule in iptables, it’ll get blocked anyway.
Creates an NWFilter for the given instance.
In the process, it makes sure the filters for the provider blocks, security groups, and base filter are all in place.
Compose a filter of drop rules from specified cidrs.
Update rules for all instances.
This is part of the FirewallDriver API and is called when the provider firewall rules change in the database. In the prepare_instance_filter we add a reference to the ‘nova-provider-rules’ filter for each instance’s firewall, and by changing that filter we update them all.
Set up basic filtering (MAC, IP, and ARP spoofing protection)
Clear out the nwfilter rules.