Comment 7 for bug 1659376

There is an additional security argument for this feature.

Right now, if you want to deploy a container onto a space, that space must be configured with an active IP address on the metal host.

You can configure an interface in MAAS with the space defined but the IP unconfigured. In this case, while the interface and it's MTU will be written to the interfaces file, juju will not recognize the host as having an interface on that space and deployment of a container will fail.

It is completely possible to still create a bridge on the interface and deploy the container in this configuration, without having an IP on the host, however juju does not know how to do so.

Peter Sabaini's comment from 2017-05-31 argued that we want this same behavior to save IP addresses on the (possibly small) public subnet. But we also want this behaviour so that the metal host (often with sensitive services such as nova-compute or ceph-osd) are not exposed to a public internet subnet unexpectedly.

This has been a real issue in real deployments, public routable IPs are assigned to host only for the reason of connecting the public-api space in containers. This has resulted in the unexpected exposition of sensitive services to the public internet. There is no simple way currently to implement a firewall for such cases.

In MAAS environments we have no security groups or automatic firewalls in many cases to work around this issue.

If we need to move this use case into a separate bug, let me know. It's a bit borderline as it's closely related but technically is a different use case to wanting a raw interface to use for other purposes.