Restrict unit ssh access via security groups

[Andrea Ieri]

The default security groups that Juju generates allow ssh access from any source.
If units are all deployed in a single space, this effectively exposes port 22 to whichever other instance has been deployed in the same network.
It would be beneficial to be able to limit the source to a configurable cidr range, perhaps as a model config option.

The objective of this bug report is similar to the one of LP:1321407, although that bug report is concerned with exposed ports, whereas this is about default security groups. I therefore think the two should be kept separate.

[Ian Booth (wallyworld)]

We have the basis for this functionality in the agent already, but it's not (yet) used when creating security groups, ie it just needs to be wired up.

eg
$ juju set-firewall-rule ssh --whitelist 192.168.1.0/8,10.10.1.0/8

The other options are "juju-controller" and "juju-application-offer"

eg
juju set-firewall-rule juju-controller --whitelist 192.168.1.0/8
juju set-firewall-rule juju-application-offer --whitelist 192.168.1.0/8

The "juju-controller" rule is meant to limit client connections to the controller.

The "juju-application-offer" rule is the only one currently supported fully - it is used to limit cross model consumer connections to offered applications.

[John A Meinel (jameinel)]

I had forgotten that we had done this, but I also don't see where it is
actually wired into the firewaller. At least JujuControllerRule doesn't
seem referenced outside of the API, and I didn't see any references to it
in worker/firewaller.

On Fri, Aug 30, 2019 at 6:15 AM Ian Booth <email address hidden> wrote:

> We have the basis for this functionality in the agent already, but it's
> not (yet) used when creating security groups, ie it just needs to be
> wired up.
>
> eg
> $ juju set-firewall-rule ssh --whitelist 192.168.1.0/8,10.10.1.0/8
>
> The other options are "juju-controller" and "juju-application-offer"
>
> eg
> juju set-firewall-rule juju-controller --whitelist 192.168.1.0/8
> juju set-firewall-rule juju-application-offer --whitelist 192.168.1.0/8
>
> The "juju-controller" rule is meant to limit client connections to the
> controller.
>
> The "juju-application-offer" rule is the only one currently supported
> fully - it is used to limit cross model consumer connections to offered
> applications.
>
>
> ** Changed in: juju
> Milestone: None => 2.7-beta1
>
> ** Changed in: juju
> Status: New => Triaged
>
> ** Changed in: juju
> Importance: Undecided => High
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1842008
>
> Title:
> Restrict unit ssh access via security groups
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1842008/+subscriptions
>

[Ian Booth (wallyworld)]

@jam it's used in the method updateForRemoteRelationIngress()

cidrs := set.NewStrings()
// If the unit is exposed, allow access from everywhere.
if unitd.applicationd.exposed {
    cidrs.Add("0.0.0.0/0")
} else {
    // Not exposed, so add any ingress rules required by remote relations.
    if err := fw.updateForRemoteRelationIngress(unitd.applicationd.application.Tag(), cidrs); err != nil {
        return nil, errors.Trace(err)
    }
}

[Jose Delarosa (jdelaros1)]

Richard,

Is the fix to this issue not going to be in v2.7 after all?

I have a customer waiting on a fix for this.

Thank you,
Jose Delarosa

[Richard Harding (rharding)]

No, this is not possible for 2.7 as it's in RC. We're working on the some of the exposed/ports parts in the 20.04 cycle. We can try to make an extended look at this but given that controller machines are intended to be able to be ssh'd to if the user has access I'm not sure what the right fix is here.

If we have to solve an immediate customer need I might suggest we deploy a firewall onto the machines and get specific on what's required for that specific use case as we don't currently have a mechanism to model this correctly.

[Yoshi Kadokawa (yoshikadokawa)]

Is this still not implemented in juju v2.8.7?
From the help, I see that the currently supported service is `ssh`

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

However, even after configuring whitelist cidr for ssh, I still see security groups created with 22/tcp inbound for 0.0.0.0/0

[Ian Booth (wallyworld)]

No, it's not yet implemented sorry.
We were looking to possibly change how this sort of thing is modelled and haven't been able to allocate the time to do the work.