[RFE] Metadata Support Across Routed Subnets
Bug #1732534 reported by
Dan Sneddon
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ironic |
In Progress
|
Wishlist
|
Dan Sneddon |
Bug Description
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.
Changed in ironic: | |
assignee: | nobody → Dan Sneddon (dsneddon) |
status: | New → In Progress |
Changed in ironic: | |
importance: | Undecided → Wishlist |
tags: | added: rfe |
To post a comment you must log in.
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.