Default Model SG Rules

James Beedy jamesbeedy at gmail.com
Fri Jan 27 17:59:43 UTC 2017


On Fri, Jan 27, 2017 at 9:45 AM, Samuel Cozannet <
samuel.cozannet at canonical.com> wrote:

> I am having similar questions / requests from other users, so +1 from me
> (actually +3). Plus I like the sshallownes of ssh-allow.
>
> Another request I have heard is get the ability to associate an IAM role
> attached to the instances. Currently Juju doesn't attach any role to the
> instances, which means it's never possible to add one once the instances
> are up & running.
> Having a simple role equivalent to admin (* on * essentially) would
> empower users to modify that role at a later point in time.
> For example, in the context of Kubernetes, this would allow instances to
> create ELB endpoints.
> Or, in other use cases, having access to an S3 bucket would help doing
> backup without requiring credentials.
>

+100 for the IAM role. This would be absolutely huge!

Both feature though work well in clouds and do not map very well to MAAS /
> Manual provider, so there is a risk of creating discrepancies in
> experience.
>

True - something that might need a lazy approach to use what is available
instead of the current way this is handled in that provider specific
configs are viewed as dependencies. I'm sure you guys have thought this
approach out well though ...


> SSH access can eventually be managed also via a lambda or simple cron
> reacting to new instances that have the juju tags, and mapping security
> rules to that (so different models could have different rules)
> This is not true of instance role though.
>

Totally. Although a valid approach, this sounds like it manual workload
that I would incur often, and can see this becoming highly unmanageable on
a linear scale.


> Thoughts on that one James?
>

Thanks for the feedback! Hopefully we can get some steam behind this!


> ++
> Sam
>

>
>
> --
> Samuel Cozannet
> Cloud, Big Data and IoT Strategy Team
> Business Development - Cloud and ISV Ecosystem
> Changing the Future of Cloud
> Ubuntu <http://ubuntu.com>  / Canonical UK LTD <http://canonical.com> /
> Juju <https://jujucharms.com>
> samuel.cozannet at canonical.com
> mob: +33 616 702 389
> skype: samnco
> Twitter: @SaMnCo_23
> [image: View Samuel Cozannet's profile on LinkedIn]
> <https://es.linkedin.com/in/scozannet>
>
> On Fri, Jan 27, 2017 at 6:33 PM, James Beedy <jamesbeedy at gmail.com> wrote:
>
>> A default SG rule generated for every model allows 22 from 0.0.0.0/0,
>> I'm guessing this is because we are trying to facilitate the use case for
>> juju deployed on a public cloud, and instances being ssh accessed from the
>> internet and not from behind VPN in the same address space.
>>
>> A functionality which would allow users who don't want ssh open to the
>> world to close it, either completely, or limit to a private address space,
>> would be very helpful (especially because Juju reverts any changes made to
>> the SG, so I couldn't even lock down port 22 if I wanted to).
>>
>> Is it possible to introduce a model config param that we could use to
>> tell juju where to allow ssh traffic from?
>>
>> Quick fix: Introduce an 'ssh-allow' param that could be used to open and
>> close port 22 on the SG generated for the model?
>>
>> Better fix: Introduce a config param 'ssh-access', where default value is
>> 0.0.0.0/0, which could then be modified to an address space that fits
>> the users security needs.
>>
>> How do others feel about this?
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170127/d3f72051/attachment.html>


More information about the Juju mailing list