[RFE] Metadata Support Across Routed Subnets

[Dan Sneddon]

Currently it can be assumed that when an Ironic node boots, the Neutron (or other) DHCP server is on the same subnet as the host. Once DHCP relay support lands, it will be possible to boot a node across a router boundary, with DHCP relay on the top-of-rack routing switch forwading the DHCP packet. There needs to be a way to support the 169.254.169.254/32 route in a way that the packet is forwarded to the metadata agent.

It isn't yet clear whether this will require any code changes, it may just be that this needs to be properly documented. This [RFE] bug should act as a placeholder until it is determined whether code+doc or only doc changes are required.

[Julia Kreger (juliaashleykreger)]

I suspect this may work out of the box depending on how an installation is architected, built, and configured networking wise. Some of the nova options allows the nova service to directly perform the source lookup and translate that to an instance-id in order to return the data, alternatively neutron can service the requests by using the 168.254.169.254 address (via nat/mangle rules https://github.com/openstack/neutron/blob/master/neutron/agent/metadata/driver.py lines ~169-191) on a router or dhcp instance, and then shifts the traffic to haproxy for the metadata proxy.

Of course, even then, it still may depend on how things are built with regards to routing.

I don't think any code changes are necessary, although after looking at the code, I can't help but wonder if we should encourage operators to disable metadata services when using routed networks, since this begins to become more and more of a possible security issue from the standpoint of how the requests get handled and passed along (i.e.) source IP address based, coupled the nature of the metadata being used as an initial configuration/hints to setup a node.

My main line of thinking is for an attacker to try and identify a neighboring node's IP address, then spam the network with arp traffic, at which point they could begin to attempt to poll the metadata service with the neighbor's source IP in order to obtain that node's metadata information.

Granted, An operator might be able to implement mitigating controls, but we are not in a place to dictate controls to mitigate security risks in an unknown infrastructure.

[Dan Sneddon (dsneddon)]

Thank you for the input, Julia. You bring up a good point about security of the metadata service, although I would rather that we document the exposure than assume that nobody would ever want that configuration. There may be closed environments where this architecture is desired and all tenants are trusted.

There is more than one way to configure an Ironic server, and improvements in BFV may play a role in routed environments as well.

[Vasyl Saienko (vsaienko)]

This looks like documentation issue, I don't think we can do anything on Nova/Neutron/Ironic side.
Metadata may be configured in two ways with routed network:

1. Via forcing config drive - that is recommended way for my opinion.
2. Via setting NAT rules on L3 device that perform DHCP relay.

[Julia Kreger (juliaashleykreger)]

In theory, at least with noop, deployment across routed networks can work today, so I think it is okay for us to go ahead and update the documentation now to indicate the risk and the basic method of operation as to how someone might wish to use it. At the same time, we can recommend use of configuration drives. I see this as a paragraph or two in the documentation and a warning box in for the security risk that exists.

You raise a good point about BFV, maybe, at some point, we might want to consider seeing if we could append metadata to the volume, although I think the minimum volume grow size was 20GB when I last looked, which caused us to discount that as a possibility. Maybe one day more mechanics could allow us to attach, add/update, and detach the volume. SOOO many use cases.