Yes, this is expected behavior. Allows address pairs were mainly intended for a few extra IP addresses that the port owns. Using /0 implies that the Neutron port is responsible for all of those addresses. So if you allow traffic from that Neutron port, it allows traffic from /0.
The router use-case should probably be documented to use either a separate security group or to disable the security groups completely on the router port using the port-security-enabled flag. http://specs.openstack.org/openstack/neutron-specs/specs/kilo/ml2-ovs-portsecurity.html On Tue, Jun 30, 2015 at 6:42 PM, James Dempsey <jam...@catalyst.net.nz> wrote: > Hi All, > > Would someone help me understand some potentially dangerous interactions > between allowed_address_pairs and security groups? My cloud is Icehouse > at the moment, but the behaviour seems unchanged in master. [1] > > Suppose a User wants to build an instance that acts as a router. > > User creates an instance named ROUTER with an interface that has an > allowed_address_pair of 0.0.0.0/0. (to bypass the anti-spoofing security > group feature) > > By default, ROUTER is in the 'default' security group. > > User also creates an instance named WEB. > > By default, WEB is in the 'default' security group. > > The 'default' security group allows inbound traffic from other hosts(and > associated allowed_address_pairs) in the 'default' security group. > > Now, WEB receives all traffic from 0.0.0.0/0 because User didn't realize > that allowed_address_pairs associated with ROUTER would effectively > change all associated security groups to be fully permissive. > > > Have I missed something? This seems like exceedingly dangerous > behaviour. I've already seen two instances of this from my users. > > [1] > > https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_rpc_base.py#L287 > > Cheers, > James > > > -- > James Dempsey > Senior Cloud Engineer > Catalyst IT Limited > +64 4 803 2264 > -- > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev