expose does not permit limited to a specific subnet range

[Richard Harding]

It is often more secure and better practice to only expose access to services to a specified subnet range. In this way, I could deploy my kubernetes to AWS, but limit external access to only the IP addresses from my company offices.

This entails additional flags on the expose command from the end user on either a subnet range or a list of known IP addresses that would be tied into the firewall rules when an application is exposed and the ports are opened up.

This type of work might be useful/going on for CMR work and so this might be something useful to think on in the current flight of features.

[Ian Booth (wallyworld)]

The internal provider firewaller APIs have already been refactored to supported opening ports for specific subnets, with "open to the world" being just a case of using CIDR 0.0.0.0/0. Yes, this was done for cross model relations.

It's now relatively straight forward to adjust the internal Juju model to record a subnet range for an expose operation.

[Tim Penhey (thumper)]

I think this should be solved by specifying a space for the application.

[Tom Barber (spicule)]

Thanks for filing the bug Rick, it would certainly be a useful feature for apps where you want business wide access but possibly without users having to authenticate. Also keeps people who like to get pen tested happy because the ports aren't open to the general public.

[John A Meinel (jameinel)]

We could use a space, but we would need to model "spaces that you can't use for deploy" first. At least from what I've seen, this has mostly been about exposing your services to other networks (eg, expose from AWS to my private cloud, without exposing to anyone else).
But you can't deploy "on AWS" to my private cloud.

I think we'll need to make sure to capture various people's desires on this to know whether the space abstraction is going to get in the way, or help. On one hand, it gives you a rather nice way to build up a 'name' for the other place/ips/etc. On the other hand, if each application that you expose gets a *different* custom list of addresses, then you just end up with space-name-soup.

I would probably also recommend starting with spaces, just want to be careful about expectations, etc. (Other problems are that if both sides are modeled in Juju, and someone creates space names that match each side, they won't *actually* be synchronized, which may lead to user confusion.)

Also, when we've talked about having 'juju expose' to a space, it has generally been more about making sure the application was *available* in that space, rather than making sure it was available *from* that space. (put Wordpress into the 55.* public addresses), so we'll need to be a little bit careful as we do more towards driving the firewall, rather than driving the machine's IP address lists.

[John A Meinel (jameinel)]

(I'm pretty sure we have other bugs for this, but we should also only expose an endpoint at a time, not everything in an application, but that also requires charm work because I don't think we track which ports are opened for what endpoint yet.)

[Achilleas Anagnostopoulos (achilleasa)]

All the required bits for supporting this feature have already landed on the develop branch. I have added a small writeup of how everything works together here: https://discourse.juju.is/t/granular-control-of-application-expose-parameters-in-the-upcoming-2-9-juju-release/3597.

As there is still an outstanding (currently under review) PR for `juju bundle-diff`, I have marked this as in-progress and will update it to fix committed once that PR lands.