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 <[email protected]>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 <[email protected]> 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 : [email protected] > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
