<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
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>On Dec 17, 2013, at 11:36 PM, Craig J <<a href="mailto:craig.jellick@gmail.com">craig.jellick@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<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">
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>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
</blockquote>
</div>
<br>
</div>
</body>
</html>