No, there haven't been vulnerabilities where the rules you expressed in the API were not rendered as requested (unless there was a denial of service in which case the whole dataplane would fail to wire). The issues were people being able to escape their own anti-spoofing filtering so they could do IP spoofing and ARP poisoning. VM-local firewalls would not have helped in this case. On Mar 2, 2016 10:50 AM, "Clark Boylan" <cboy...@sapwetik.org> wrote:
> On Wed, Mar 2, 2016, at 09:38 AM, Sean M. Collins wrote: > > Kevin Benton wrote: > > > * Neutron cannot be trusted to do what it says it's doing with the > security > > > groups API so users want to orchestrate firewalls directly on their > > > instances. > > > > This one really rubs me the wrong way. Can we please get a better > > description of the bug - instead of someone just saying that Neutron > > doesn't work, therefore we don't want any filtering or security for our > > instances using an API? > > Sure. There are two ways this manifests. The first is that there have > been bugs in security groups where traffic is passed despite being told > not to pass that traffic. This has been treated as a bug in the past and > corrected which is great so this particular instance of the issue is > less worrysome. The second is that I will explicitly tell neutron to > pass traffic but for whatever reason that traffic ends up being blocked > anyways. One concrete example of this is the infra team has had to stop > using GRE because at least two of our clouds do not pass GRE traffic > despite having explicit "pass all ipv4 and all ipv6 between all possible > addresses rules". > > Security groups need to do what I have told them to do and when they > don't it is almost impossible as a cloud user to debug them. > > Clark > > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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