<div dir="ltr">Just as a follow up: you're right Amir, that was the wrong layer at which to solve the problem.<div><br></div><div>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.</div>
<div><br></div><div>Thanks!</div><div><br></div><div>-Craig</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 18, 2013 at 8:31 AM, Amir Sadoughi <span dir="ltr"><<a href="mailto:amir.sadoughi@rackspace.com" target="_blank">amir.sadoughi@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
Hi Craig,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Amir</div>
<div><br>
</div>
<div><br>
<div><div><div class="h5">
<div>On Dec 17, 2013, at 11:36 PM, Craig J <<a href="mailto:craig.jellick@gmail.com" target="_blank">craig.jellick@gmail.com</a>> wrote:</div>
<br>
</div></div><blockquote type="cite"><div><div class="h5">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Here's what we'd like to achieve:</div>
<div>1. Lock down security group (and rules) so that only admins can make modifications.</div>
<div>2. Add additional rules to the default security group that every project gets.</div>
<div>The goal is to have the default rules cover 95% of the use cases so that per-project modifications by admins are minimal.</div>
<div><br>
</div>
<div>#1 is pretty straightforward via additional policy.json rules. (Unless anyone knows of any gotchas?)</div>
<div><br>
</div>
<div>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
<a href="https://github.com/openstack/neutron/blob/d66163b772a70e8ba438d02100da303363599bd0/neutron/db/securitygroups_db.py#L105" target="_blank">
here</a>.</div>
<div><br>
</div>
<div>So, a few questions about the solution for #2:</div>
<div>1. Does our solution make sense or is there a better and/or pre-existing solution?</div>
<div>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?</div>
<div><br>
</div>
<div>Thanks in advance,</div>
<div>Craig</div>
</div></div></div>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
</blockquote>
</div>
<br>
</div>
</div>

</blockquote></div><br></div>