Specify an existing security group as model config?

[Marco Ceppi]

Hi all,

Since Juju creates a security group per model (and applies it to all
instances in that model) it makes it really easy to enable/disable features
for all applications in a single model. One such feature is AWS EFS (NFS
aaS) which just needs to know which Security Groups can mount that EFS
endpoint.

There's a problem, however, when tearing down and standing up lots of
models in a months time. EFS only allows 5 Security Groups. So if you
wanted more than five Kubernetes clusters to access a single mount you need
to start editing all the AWS instances to share that Security Group
manually.

When it comes to scaling operations this can be tedious. I know there are
configurations for VPC-ID - is there also a similar security-group setting
where either the default model SG will be set based on user input instead
of created or a setting where an additional "model" security group can be
set so instances have it in addition to the model/instance security group?

Thanks,
Marco Ceppi

[Mark Shuttleworth]

Post by Marco Ceppi
When it comes to scaling operations this can be tedious. I know there
are configurations for VPC-ID - is there also a similar security-group
setting where either the default model SG will be set based on user
input instead of created or a setting where an additional "model"
security group can be set so instances have it in addition to the
model/instance security group?

I think it makes sense that the model creation process might accept such
a parameter, yes.

Does a security group per model make sense, or should it be per
application in the model (though that sounds like it might be wasteful).

Mark

[Kapil Thangavelu]

two cents, typical real world requirements vary, in the enterprise you
might have various tiering by architectural layer (front end waf elb
ingress, waf servers, set of dmz components/web servers, set of app
servers, set of dbs) all structured out with connectivity models. typically
these map to a m:n on security group basis to service model, based on the
model's responsibilities and consumers.

Post by Mark Shuttleworth

Post by Marco Ceppi
When it comes to scaling operations this can be tedious. I know there
are configurations for VPC-ID - is there also a similar security-group
setting where either the default model SG will be set based on user
input instead of created or a setting where an additional "model"
security group can be set so instances have it in addition to the
model/instance security group?

I think it makes sense that the model creation process might accept such
a parameter, yes.
Does a security group per model make sense, or should it be per
application in the model (though that sounds like it might be wasteful).
Mark
--
Juju mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/juju

[Nicholas Skaggs]

Marco, we have done a POC of this in the past as a model constraint. So,

juju bootstrap aws aws --constraints security-groups=sg1,sg2
juju set-model-constraints security-groups=sg1,sg2,...

How does that feel?

Nicholas

Post by Kapil Thangavelu
two cents, typical real world requirements vary, in the enterprise you
might have various tiering by architectural layer (front end waf elb
ingress, waf servers, set of dmz components/web servers, set of app
servers, set of dbs) all structured out with connectivity models. typically
these map to a m:n on security group basis to service model, based on the
model's responsibilities and consumers.

Post by Mark Shuttleworth

Post by Marco Ceppi
When it comes to scaling operations this can be tedious. I know there
are configurations for VPC-ID - is there also a similar security-group
setting where either the default model SG will be set based on user
input instead of created or a setting where an additional "model"
security group can be set so instances have it in addition to the
model/instance security group?

I think it makes sense that the model creation process might accept such
a parameter, yes.
Does a security group per model make sense, or should it be per
application in the model (though that sounds like it might be wasteful).
Mark
--
Juju mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
an/listinfo/juju

--
Juju mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/juju

[Marco Ceppi]

This would be a good start, but this will likely end up being an
application level constraint.

Marco

Post by Nicholas Skaggs
Marco, we have done a POC of this in the past as a model constraint. So,
juju bootstrap aws aws --constraints security-groups=sg1,sg2
juju set-model-constraints security-groups=sg1,sg2,...
How does that feel?
Nicholas

Post by Kapil Thangavelu
two cents, typical real world requirements vary, in the enterprise you
might have various tiering by architectural layer (front end waf elb
ingress, waf servers, set of dmz components/web servers, set of app
servers, set of dbs) all structured out with connectivity models. typically
these map to a m:n on security group basis to service model, based on the
model's responsibilities and consumers.

Post by Mark Shuttleworth

Post by Marco Ceppi
When it comes to scaling operations this can be tedious. I know there
are configurations for VPC-ID - is there also a similar security-group
setting where either the default model SG will be set based on user
input instead of created or a setting where an additional "model"
security group can be set so instances have it in addition to the
model/instance security group?

I think it makes sense that the model creation process might accept such
a parameter, yes.
Does a security group per model make sense, or should it be per
application in the model (though that sounds like it might be wasteful).
Mark
--
Juju mailing list
https://lists.ubuntu.com/mailman/listinfo/juju

--
Juju mailing list
https://lists.ubuntu.com/mailman/listinfo/juju

--
Juju mailing list
https://lists.ubuntu.com/mailman/listinfo/juju