7.4 KiB
Multiple PXE filtering backends
https://bugs.launchpad.net/ironic-inspector/+bug/1665666
This is a part of the HA inspector effort1, of the tripleo routed networks ironic inspector effort2 and of the Pike PTG inspector architectural session outcome3.
Problem description
To prevent interference with normal PXE boot of ironic bare metal nodes the inspector has to employ filtering of the "inspection" PXE traffic. Therefore a filter has to block nodes not being inspected while nodes being inspected have to be explicitly white-listed. Considering the discovery feature, unknown nodes have to be allowed to boot the inspection image.
inspector currently supports only an L2-based
iptables
filter or no filtering option. While functional in
the flat-network scenario, the iptables
filter comprises a
scaling bottleneck and a safety issue. For the leaf-and-spine
use case, where the DHCP PXE requests are relayed through a Top-Of-Rack
switch, current iptables
black-listing cannot be used
anymore as the source MAC address of the original DHCP frames is
replaced with the TOR MAC address when crossing the L2 broadcast domain.
In case of a dedicated discovery network, the PXE filtering is not
necessary any more.
To support these use cases and to allow vendor-specific solutions
we'd like to propose abstracting the inspection PXE traffic filtering
into a driver interface. This could be implemented in an *aaS
fashion, such as neutron, or by directly controlling
the DHCP service i.e talking to dnsmasq
over its D-Bus
interface. An intelligent TOR switch might be capable of filtering the
relay traffic directly. A noop driver would be used in case of the
dedicated discovery network.
Proposed change
Since essentially the filtering is an ironic vs inspector vs filter synchronization problem, we propose a discrete PXE filtering driver interface that comprises of these idempotent methods that must not lock any node items:
__init__(self)
synchronous; creates per-process "singleton" instance of-
the filter driver; called by stevedore to configure the filter driver.
init_filter(self)
may be synchronous; initializes internal filter state. This method may perform system-wide filter state changes.sync(self, ironic=None)
called in a background thread; performs the synchronization between ironic, inspector and the driver internal state e.g updatingiptables
.tear_down_filter(self)
may be synchronous; resets internal filter state. This method may perform system-wide filter state changes.
This abstract interface shall reside in inspector
tree, together with an iptables
and a noop
driver implementation.
In addition, a generic get_periodic_sync_task
filter driver method shall be provided that particular driver
implementations may consider overriding to e.g opt-out from the periodic
synchronization.
Any driver-specific High-Availability concerns are out of scope of this spec and the inspector code base and should be addressed by particular drivers internally.
Alternatives
Select a couple of supported, in-tree located filters without the possibility to extend the set by vendors.
Data model impact
None
HTTP API impact
None
Client (CLI) impact
None
Ironic python agent impact
None
Performance and scalability impact
We hope to see custom PXE filter drivers help the inspector to scale beyond the current firewall-based filtering bottleneck.
Security impact
None
Deployer impact
- A new configuration option
pxe_filter_driver
is introduced pointing inspector to particular filtering driver. Default value shall beiptables
. - The
firewall.*
configuration options are deprecated and renamed toiptables.*
- The
pxe_filter_driver
configuration option shall take precedence over theiptables.*
configuration option. - The
iptables.manage_firewall
configuration option shall be deprecated and ignored. - The
firewall.firewall_update_period
configuration option shall be deprecated and ignored. - Deployer might consider custom drivers fitting their needs.
- A "standard" grenade testing with the firewall-based driver will be performed in the upstream inspector CI gate to assert the upgradability.
Developer impact
Developers of custom PXE filter drivers should adhere to the proposed driver interface. Any specific High-availability considerations should be addressed by the drivers internally. The stevedore library will be used to implement the driver loading mechanism.
Implementation
To illustrate what a driver implementation may look like we list what
information will a particular driver have to deal with internally,
comparing possible sync
method implementations of the
drivers.
Driver | Whitelist | Blacklist | Discovery support |
---|---|---|---|
neutron | Update the PXE port with the inspection network ID | Clear the inspection network ID on the PXE port | N/A (a separate VLAN) |
dnsmasq | Allow a lease for a MAC address explicitly | Deny a lease for a MAC address explicitly | Grant leases by default |
iptables | Subtract the MAC addresses from the blacklist | Deny access for the MAC addresses | Accept DHCP traffic by default |
Assignee(s)
- Primary assignee:
-
<milan k (vetrisko)>
Work Items
- introduce the abstract driver interface
- refactoring current firewall-based filter
Dependencies
None
Testing
Unit tests covering the interface and default implementations will be added. A "standard" Grenade CI gate job will assert upgradability of inspector with the default firewall-based filter.