Open Stack

Just as a follow up: you're right Amir, that was the wrong layer at which
to solve the problem.

I was thrown off by the fact that Horizon silently creates the default
security group when you hit that page for the first time. In fact, I wasn't
sure when/how it was getting created. Now that I know that it's just an API
call from Horizon, it makes total sense to add this to our project creation
workflow.

Thanks!

-Craig


On Wed, Dec 18, 2013 at 8:31 AM, Amir Sadoughi
<amir.sadoughi at rackspace.com>wrote:

>  Hi Craig,
>
>  Regarding #2, IMHO, I think that would be solving your security group
> issues at the wrong layer. As an admin you could create the default
> security group for the tenant with the rules you would like via API. In
> other words, I would automate the creation of the default security group
> rules in a script rather than as a side-effect of Neutron’s
> create_security_group function.
>
>  Amir
>
>
>  On Dec 17, 2013, at 11:36 PM, Craig J <craig.jellick at gmail.com> wrote:
>
>  Hi all,
>
>  In the private cloud that we are building out, we'd like to restrict
> what users can do with security group rules. We have a solution in mind and
> would like to vet it in the mailing list.
>
>  Here's what we'd like to achieve:
> 1. Lock down security group (and rules) so that only admins can make
> modifications.
> 2. Add additional rules to the default security group that every project
> gets.
> The goal is to have the default rules cover 95% of the use cases so that
> per-project modifications by admins are minimal.
>
>  #1 is pretty straightforward via additional policy.json rules. (Unless
> anyone knows of any gotchas?)
>
>  For #2, we think we need something a little more elaborate: we want to
> define all the additional rules in a config file (perhaps a yaml file) and
> then create them when the default security group is created here<https://github.com/openstack/neutron/blob/d66163b772a70e8ba438d02100da303363599bd0/neutron/db/securitygroups_db.py#L105>
> .
>
>  So, a few questions about the solution for #2:
> 1. Does our solution make sense or is there a better and/or pre-existing
> solution?
> 2. (Maybe this is a question for the dev list) Would this solution be
> valuable to the rest of the community or is it too narrow a use case? Is it
> something we should blueprint?
>
>  Thanks in advance,
> Craig
>  _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131223/d6fa40f1/attachment.html>