lock down security group rules by default

Bug #1661275 reported by james beedy
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical Juju
New
Undecided
Unassigned

Bug Description

Following a recent security group audit, I'm catching a lot of flack due to the ports being exposed by default on my Juju deployed instances. Can we work toward finding a more secure default implementation here?

It seems my instances inherit the default security group rules for the model. I understand why port 22 is needed (22 isn't always accessed from 0.0.0.0/0), but why 17070?

See attached screen shot of the ports that are opened by default on my instance, ports that have no rhyme or reason to be open(17070). Whats worse, Juju prevents me from modifying/removing these rules by reverting any manual changes I may make. I can't lock down my instances if I wanted to (which I do). I feel this is a scary thing to force upon anyone.

Not sure what the best approach is for this, but would appreciate some consideration and/or feedback.

Thanks

Revision history for this message
james beedy (jamesbeedy) wrote :
description: updated
description: updated
james beedy (jamesbeedy)
description: updated
description: updated
description: updated
description: updated
description: updated
Revision history for this message
John A Meinel (jameinel) wrote :

The rules there allow all of the instances in the model to talk to each other but only machines in the model.
The other rule allows inbound ssh to all machines.
Charms currently only declare ports that need to be open if you expose them to the outside world. They don't declare the ports they need to communicate privately.

james beedy (jamesbeedy)
description: updated
description: updated
description: updated
description: updated
Revision history for this message
Ronald (rahworkx) wrote :

Are there any parameters that can be set in the charm to segregate ssh access to an internal subnet i.e. 20.0.0.0/16. A blanket allow all to ssh isn't good practice. This should be addressed moving forward.

Revision history for this message
Michael Nelson (michael.nelson) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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