Fine grain secgroup rules

could you elaborate on what you mean by fine grain secgroups, and how for example you might want to see it exposed? nrpe checks could do open-port when an nrpe rel is established (assuming not doing external-nrpe, in which case the charm can open-port in config-changed).

Possibly related to https://bugs.launchpad.net/juju-core/+bug/1420996 btw? Secgroups rules for SSH are being reset periodically without users consent, so they are pretty useless depending on the scenario if you are affected by this other bug.

Yeah, it's related. In most of our environments, we lock down various services such as NRPE, rsync, HAProxy stats (and others) to a specific source. Every time jujud on machine 0 runs, it resets those rules as per (LP:1420996).

So something like:

juju add-secgroup-access --service haproxy 91.189.90.111/32 tcp 873
juju add-secgroup-access --service haproxy 91.189.90.111/32 tcp 10000
juju add-secgroup-access --service haproxy 91.189.90.111/32 icmp 0

Or:

juju add-secgroup-access --machine 0 91.189.90.111/32 tcp 22

'juju open-port' doesn't work in our case because it opens access to all and there are some additional things we want.

NOTE: this should be for all providers and not just OpenStack.

To explain why we think this is important for Canonical IS: we need source-address-based access control for certain services. Examples of this are:

- public web sites fronted by haproxy: haproxy needs to expose port 80/443 to the world, but port 10000 (haproxy stats interface) should only be exposed to the administrators and/or developers

- ssh access for administrators/developers: we usually want to lock this down to VPN users only

- Nagios checks: only our Nagios server(s) should be allowed to run checks against the Nagios agent.

In order to do this at present, we manually edit the secgroup rules, but this causes problems in situations when juju itself resets secgroups, such as those encountered in bugs #1420996 #1449044 #1555969.

I would consider this functionality to be around medium priority. We shouldn't have to come along fixing firewall rules after juju has created them. Even adding the ability to specify a single CIDR to a juju expose would be a huge step forward.

This is still something we would very much like to see

We have the start of this functionality which landed in Juju 2.3.
It only supports (so far) 3 pre-defined "well known" services
 -ssh (port 22)
 -juju-controller (client connections to controller on port 17070)
 -juju-application-offer (cross model relation consumers on port 17070)

It terms of restricting access to particular deployed services, this really falls under the open/close port functionality of a charm doesn't it? eg for haproxy, open port 10000 does currently expose to 0.0.0.0/0 so we need to look at enhancing what open-port can do to allow a CIDR to be specified. The Juju firewaller internally now does support CIDRs (with the set-firewall-rule addition) so we just need to enhance what open-port can specify.

$ juju set-firewall-rule --help
Usage: juju set-firewall-rule [options] <service-name>, --whitelist <cidr>[,<cidr>...]

Summary:
Sets a firewall rule.

Options:
-m, --model (= "")
    Model to operate in. Accepts [<controller name>:]<model name>
--whitelist (= "")
    list of subnets to whitelist

Details:
Firewall rules control ingress to a well known services
within a Juju model. A rule consists of the service name
and a whitelist of allowed ingress subnets.
The currently supported services are:
 -ssh
 -juju-controller
 -juju-application-offer

Examples:
    juju set-firewall-rule ssh --whitelist 192.168.1.0/16
    juju set-firewall-rule juju-controller --whitelist 192.168.1.0/16
    juju set-firewall-rule juju-application-offer --whitelist 192.168.1.0/16

See also:
    list-firewall-rules

Yes, it does fall under the open/close port functionality of a charm - open-port accepting CIDRs would very likely cover our needs.

I can see supporting a flag to "juju expose <APP>:<ENDPOINT> <TO>" rather
than a generic "expose exposes to all". But I don't think the *charm*
should need to be aware of what CIDR it is being exposed to.

We would need changes to the hook tool "open-port" to be able to declare
"open this port for this endpoint", but in lieu of that, we could add
support for "juju expose APP SPACE" without charm changes.

But really it is the Operator that would be supplying CIDR/SPACE not the
*charm*.

On Fri, Oct 12, 2018 at 2:50 PM Junien Fridrick <email address hidden>
wrote:

> Yes, it does fall under the open/close port functionality of a charm -
> open-port accepting CIDRs would very likely cover our needs.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1287658
>
> Title:
> Fine grain secgroup rules
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1287658/+subscriptions
>

What if a charm wants to open a port to all, but another port to only a specific CIDR ?

Again, a *charm* should not know where it should be open to, because CIDR
is a sysadmin rule. A charm shouldn't know where it is deployed.
If we did want that sort of flexibility, that is where the charm would
advertise multiple endpoints, and then have the charm label the "open-port"
with which endpoint it would be associated with. And then the sysadmin
would "juju expose APP:ENDPOINT CIDR".
That should put the knowledge and abstractions correctly. It does require
changes to 'open-port' to allow the binding and to 'juju expose' to allow
specifying both a CIDR/space and an endpoint.

On Wed, Oct 17, 2018 at 4:56 PM Junien Fridrick <email address hidden>
wrote:

> What if a charm wants to open a port to all, but another port to only a
> specific CIDR ?
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1287658
>
> Title:
> Fine grain secgroup rules
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1287658/+subscriptions
>

Works for me :)

Got hit by this bug again, so here's a reminder that this is still impacting us :)

Thanks !

In 2.9 we will have updated support for 'juju expose'
https://discourse.charmhub.io/t/granular-control-of-application-expose-parameters-in-the-upcoming-2-9-juju-release/3597

It would be good to know if this addresses the core needs, or if it is incomplete. (IIRC there might be a remaining issue around 'ssh' which isn't otherwise explicitly exposed.)

On Thu, Apr 22, 2021 at 03:14:33PM -0000, John A Meinel wrote:
> In 2.9 we will have updated support for 'juju expose'
> https://discourse.charmhub.io/t/granular-control-of-application-expose-parameters-in-the-upcoming-2-9-juju-release/3597
>
> It would be good to know if this addresses the core needs, or if it is
> incomplete. (IIRC there might be a remaining issue around 'ssh' which
> isn't otherwise explicitly exposed.)
>

For us, I think `expose --to-cidrs` addresses the core needs of this
bug. The only other being `ssh` as you mentioned.