security groups don't work with LBaaS vip and ovs plugin

[Aaron Rosen]

http://codepad.org/xU8G4s00

I pinged nachi and he suggested to try using:

interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver

But after setting this it seems like the vip does not work at all.

[Aaron Rosen (arosen)]

We're thinking this is because there is no OVSHybrid driver in quantum for the agent to use.

[Nachi Ueno (nati-ueno)]

Diagram is here
https://docs.google.com/presentation/d/15mpiFyilGvHFEEOw1Ytv2uSb80nW0KjEBRlHI4qOO8g/edit#slide=id.gb876186f_05

tap for lbaas is directly connected to the openvswitch, so we need similar driver as OVSHybrid stuff

[Nachi Ueno (nati-ueno)]

I tested security group + vip + linux bridge plugin, and it is working

[yong sheng gong (gongysh)]

I think we should implement SG via flow rules. OVSHybrid on compute is deprecated, are u sure we should keep it and use it on the agent side? Personally, I don't like OVSHybrid way since it needs linux bridge and ovs bridge at the same time. Some OSes does not support to run them at the same time.

[dan wendlandt (danwent)]

On Tue, Apr 2, 2013 at 5:00 PM, yong sheng gong
<email address hidden>wrote:

> I think we should implement SG via flow rules. OVSHybrid on compute is
> deprecated, are u sure we should keep it and use it on the agent side?
>

I'm surprised to hear this. In my understanding, it is no more deprecated
than any other specific vif-plugging class, all of which are being shifted
to using port-bindings. The approach is still in use though.

> Personally, I don't like OVSHybrid way since it needs linux bridge and
> ovs bridge at the same time. Some OSes does not support to run them at
> the same time.
>

all newer kernels should support running them both. I'm not aware of a
widely used OS platform that both has support for OVS and does not support
both running simultaneously. There may be some out there, but I don't
think its been a problem so far.

>
> --
> You received this bug notification because you are a member of Netstack
> Core Developers, which is subscribed to quantum.
> https://bugs.launchpad.net/bugs/1163569
>
> Title:
> security groups don't work with vip and ovs plugin
>
> Status in OpenStack Quantum (virtual network service):
> New
>
> Bug description:
> http://codepad.org/xU8G4s00
>
> I pinged nachi and he suggested to try using:
>
> interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver
>
> But after setting this it seems like the vip does not work at all.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/quantum/+bug/1163569/+subscriptions
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Hua Zhang (zhhuabj)]

I think it seems doesn't exist security group issue only by my theoretical analysis (I haven't done this test).
good picture https://docs.google.com/presentation/d/15mpiFyilGvHFEEOw1Ytv2uSb80nW0KjEBRlHI4qOO8g/edit#slide=id.gb876186f_05

1) for the compute node which the lb service located in, it's just a common vm, so it should have following firewall rules.
   -A nova-compute-local -d 10.0.0.8/32 -j nova-compute-haproxy-instance
   -A nova-compute-haproxy-instance -s 10.0.0.0/24 -j ACCEPT
   -A nova-compute-haproxy-instance -s 10.0.0.1/32 -p udp -m udp --sport 67 --dport 68 -j ACCEPT
   -A nova-compute-haproxy-instance -j nova-compute-sg-fallback
   -A nova-compute-sg-fallback -j DROP
  at the same time, it also has a routing rule for vip to connect it's gateway in the l3-agent although it has it's own namespace default-sg
   route add default gw 10.0.0.1

2) vip should can visit other vm of lb pool because l3-agent has following firewall rules
   -A nova-network-POSTROUTING -s 10.0.0.0/8 -d 10.0.0.0/8 -m conntrack ! --ctstate DNAT -j ACCEPT

[Thierry Carrez (ttx)]

Could you explain the security impact here ?

[Thierry Carrez (ttx)]

Clearing the security flag. Please set it again if you think it was warranted and can explain why.

[GMi (gmi)]

The problem is that once you assign a VIP to an LB there is no way to allow only specific IPs to reach that VIP.
Basically, the LB's VIP is reachable from the entire Internet, and even if you use "neutron port-list" to find the port of the VIP and apply a security group to it there is no difference.

The security implication is that the security rules applied to the Neutron's VIP port of the LB are not in fact enforced.

This is on Icehouse running on Ubuntu 12.04

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/109848

[Thierry Carrez (ttx)]

Waiting on neutron-coresec confirmation of the issue

[Aaron Rosen (arosen)]

This has been a known bug before the lbaas stuff shipped in Grizzly (and was in the release notes then if i remeber correctly) that vips don't enforce security groups with the OVS/ML2 plugin as there is no OVSHybrid driver in neutron. I don't think we need to issue a security note on this.

[Jeremy Stanley (fungi)]

It sounds like there's no need for the VMT to issue a security advisory, but it does seem like something the OSSG might be interested in documenting more visibly so I've tagged it to the ML in case they do.

[Robert Clark (robert-clark)]

Could be OSSN worthy, I'll throw it on our queue for discussion.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Salvatore Orlando (<email address hidden>) on branch: master
Review: https://review.openstack.org/109848
Reason: This patch has been inactive long enough that I think it's safe to abandon.
The author can resurrect it if needed.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kyle Mestery (<email address hidden>) on branch: master
Review: https://review.openstack.org/109848
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Kyle Mestery (mestery)]

Doug, assigning this to you. Can you have someone from LBaaS triage this a bit more and determine if it should still be high priority, and if the fix is simple enough? See Steve's fix from above. Thanks!

[Robert Clark (robert-clark)]

Two OSSN members have tried and failed to write an OSSN for this.

For now I've set the status to wont-fix. If there's someone from Neutron who can help with the OSSN we'll re-open.

[Kyle Mestery (mestery)]

Hoping Doug and Sean can look at this closer this week yet and answer Robert's question from #18, as well as accurately triage this one.

[Armando Migliaccio (armando-migliaccio)]

The codebase has changed so much since this bug was reported that I am no longer sure it can be confirmed. We should probably put it back to new so that someone can go and triage it.

[Miguel Angel Ajo (mangelajo)]

I will triage this again tomorrow morning.

[Miguel Angel Ajo (mangelajo)]

Sadly, I retried to triage this again today, but having issues with my dev-env which are sucking all my time. @doug, could you verify if this is still valid?

I would tend to think that no, at least with the octavia implementation, as it's a VM, it will have the port connected via standard nova ovs hybrid plug.

I guess haproxy should remain the same.

[Michael Johnson (johnsom)]

This is not an issue with Octavia.
We create and assign a security group with setting up the VIP.

[Armando Migliaccio (armando-migliaccio)]

Can't be triaged.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]