Restrict unit ssh access via security groups

Bug #1842008 reported by Andrea Ieri
272
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical Juju
Triaged
High
Unassigned

Bug Description

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.

Andrea Ieri (aieri)
information type: Private Security → Public Security
Revision history for this message
Ian Booth (wallyworld) 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
status: New → Triaged
importance: Undecided → High
Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 1842008] Re: Restrict unit ssh access via security groups

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
>

Revision history for this message
Ian Booth (wallyworld) wrote :

@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)
    }
}

Changed in juju:
milestone: 2.7-beta1 → 2.7-rc1
Changed in juju:
milestone: 2.7-rc1 → none
Revision history for this message
Jose Delarosa (jdelaros1) wrote :

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

Revision history for this message
Richard Harding (rharding) wrote :

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.

Revision history for this message
Yoshi Kadokawa (yoshikadokawa) wrote :

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

Revision history for this message
Ian Booth (wallyworld) wrote :

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.

Haw Loeung (hloeung)
description: updated
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.