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 <[email protected]> wrote: > On 10 July 2013 21:14, Vishvananda Ishaya <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
