Open Stack

Hi Ian,

For shared networks if the network is set to port_security_enabled=True
then the tenant will not be able to remove port_security_enabled from their
port if they are not the owner of the network. I believe this is the
correct behavior we want. In addition, only admin's are able to create
shared networks by default.

I've created the following blueprint
https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs and
doc:
https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharingwhich
will provide us a way to do this. It would be awesome if you could
check it out and let me know what you think.

Thanks,

Aaron


On Tue, Jul 16, 2013 at 10:34 AM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:

> On 10 July 2013 21:14, Vishvananda Ishaya <vishvananda at gmail.com> wrote:
> >> It used to be essential back when we had nova-network and all tenants
> >> ended up on one network.  It became less useful when tenants could
> >> create their own networks and could use them as they saw fit.
> >>
> >> It's still got its uses - for instance, it's nice that the metadata
> >> server can be sure that a request is really coming from where it
> >> claims - but I would very much like it to be possible to, as an
> >> option, explicitly disable antispoof - perhaps on a per-network basis
> >> at network creation time - and I think we could do this without
> >> breaking the security model beyond all hope of usefulness.
> >
> > Per network and per port makes sense.
> >
> > After all, this is conceptually the same as enabling or disabling
> > port security on your switch.
>
> Bit late on the reply to this, but I think we should be specific on
> the network, at least at creation time, on what disabling is allowed
> at port level (default off, may be off, must be on as now).  Yes, it's
> exactly like disabling port security, and you're not always the
> administrator of your own switch; if we extend the analogy you
> probably wouldn't necessarily want people turning antispoof off on an
> explicitly shared-tenant network.
> --
> Ian.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130717/32933eec/attachment.html>