On 2/11/21 8:11 PM, Jeremy Stanley wrote:
On 2021-02-11 18:45:48 +0100 (+0100), Thomas Goirand wrote: [...]
You should *not* expose your compute machines to the internet (and probably not your controller either, except the API). You should set them up with a private network address (192.168.x.x or 10.x.x.x for example). Only your VMs should have access to internet. I would strongly recommend revisiting your network setup. [...]
I'm not trying to be pedantic, but just because something has an RFC 1918 address doesn't mean it's not also exposed to the Internet (for example via a port forward, or 1:1 NAT, or through a proxy, or an interface alias, or another interface, or another address family like inet6, or...). Conversely, using globally routable addresses doesn't mean those systems are necessarily exposed to the Internet either (they could be secured behind this new-fangled contraption called a "network firewall" which is a far more thorough means of policy enforcement than merely hopes and wishes that certain addresses won't be reachable thanks to loosely obeyed routing conventions).
While not wasting global IPv4 addresses on systems which don't need to be generally reachable is probably a sensible idea from the perspective of v4 address exhaustion/conservation, it's dangerous to assume or suggest that something is secure from remote tampering just because it happens to have an RFC 1918 address on it.
I very much agree with that. On top of this, I would also suggest that the compute nodes (and in fact, any component of the infrastructure) have no access to the internet outbound as well, simply because they don't need it. To get things installed, just setup a package mirror, or a proxy. For the VMs connectivity, if using DVR, the br-ex of the compute nodes (and the network nodes) can be connected to a VLAN that will be different from the one used for managing the infrastructure. Neutron manages this pretty well. Cheers, Thomas Goirand (zigo)