[security-sig] On blindly recommending RFC 1918 addresses (was: Openstack cannot access to the Internet)

Thomas Goirand zigo at debian.org
Thu Feb 11 22:41:01 UTC 2021

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.


Thomas Goirand (zigo)

More information about the openstack-discuss mailing list