Multiple PXE filtering backends

https://bugs.launchpad.net/ironic-inspector/+bug/1665666

This is a part of the HA inspector effort 1, of the tripleo routed networks ironic inspector effort 2 and of the Pike PTG inspector architectural session outcome 3.

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 updating iptables.

  • 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 be iptables.

  • The firewall.* configuration options are deprecated and renamed to iptables.*

  • The pxe_filter_driver configuration option shall take precedence over the iptables.* 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.

Features

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.