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

Bug #1163569 reported by Aaron Rosen on 2013-04-02
38
This bug affects 6 people
Affects Status Importance Assigned to Milestone
OpenStack Security Notes
High
Unassigned
neutron
Undecided
Unassigned

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.

Aaron Rosen (arosen) wrote :

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

Nachi Ueno (nati-ueno) wrote :

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

description: updated
Nachi Ueno (nati-ueno) wrote :

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

yong sheng gong (gongysh) 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? 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.

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Aaron Rosen (arosen) on 2013-05-15
tags: added: sg-fw
Changed in neutron:
importance: Undecided → Medium
status: New → Triaged
importance: Medium → High

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

Changed in neutron:
assignee: nobody → Steven Weston (steve.weston)
Nachi Ueno (nati-ueno) on 2014-03-25
Changed in neutron:
importance: High → Medium
importance: Medium → Critical
importance: Critical → High
information type: Public → Public Security
Thierry Carrez (ttx) wrote :

Could you explain the security impact here ?

Changed in ossa:
status: New → Incomplete
Thierry Carrez (ttx) wrote :

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

information type: Public Security → Public
no longer affects: ossa
GMi (gmi) wrote :

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

Thierry Carrez (ttx) on 2014-07-09
information type: Public → Public Security

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

Changed in neutron:
status: Triaged → In Progress

Waiting on neutron-coresec confirmation of the issue

Changed in ossa:
status: New → Incomplete
Aaron Rosen (arosen) wrote :

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) on 2014-07-29
tags: added: security
no longer affects: ossa
information type: Public Security → Public
Jeremy Stanley (fungi) wrote :

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) wrote :

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

Changed in ossn:
assignee: nobody → Doug Chivers (doug-chivers)
importance: Undecided → High
status: New → In Progress

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.

Changed in ossn:
assignee: Doug Chivers (doug-chivers) → Steven Weston (steve.weston)

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) on 2015-03-31
Changed in neutron:
status: In Progress → Confirmed

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!

Changed in neutron:
assignee: Steven Weston (steve.weston) → Doug Wiegley (dougwig)
Robert Clark (robert-clark) wrote :

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.

Changed in ossn:
assignee: Steven Weston (steve.weston) → nobody
status: In Progress → New
status: New → Won't Fix
Kyle Mestery (mestery) wrote :

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.

yujie (16189455-d) on 2015-09-22
information type: Public → Public Security
information type: Public Security → Public

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.

Changed in neutron:
status: Confirmed → New
Miguel Angel Ajo (mangelajo) wrote :

I will triage this again tomorrow morning.

Miguel Angel Ajo (mangelajo) wrote :

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.

summary: - security groups don't work with vip and ovs plugin
+ security groups don't work with LBaaS vip and ovs plugin
tags: added: needs-attention
Michael Johnson (johnsom) wrote :

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

Doug Wiegley (dougwig) on 2016-01-21
Changed in neutron:
status: New → Confirmed
Changed in neutron:
assignee: Doug Wiegley (dougwig) → nobody

Can't be triaged.

Changed in neutron:
status: Confirmed → Incomplete
importance: High → Undecided
Launchpad Janitor (janitor) wrote :

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

Changed in neutron:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers