Security groups aren’t network topology aware

Bug #1432856 reported by Aleksandr Shaposhnikov
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Expired
Undecided
Unassigned

Bug Description

Security group rules for a host include all hosts that are members of the security group even though some can be unaccessible because they aren’t attached to the same router. This introduces two problems. First, it will create unneeded iptables rules on nodes and additional work on neutron-server and agent-side. Second, in the case of overlapping networks, the rules that result from a host on a completely separate network may end up allowing traffic from an untrusted host on the same network.

e.g. Security group SG1 has rules to allow traffic from other members of the same group. Members of SG1 include 10.0.0.2 and 10.0.0.3, which are on two separate networks with overlapping IPs. The iptables rules on 10.0.0.2 will then permit traffic from 10.0.0.3 even though 10.0.0.3 could be an untrusted node on its own network.

Workaround: Use separate security groups per each network. This will decrease load from calculations significantly on neutron-server and also will decrease number of iptables rules on nodes.

Tags: sg-fw scale
Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

"Second, in the case of overlapping networks, the rules that result from a host on a completely separate network may end up allowing traffic from an untrusted host on the same network."

This is a known issue with tenant isolation that is filed under https://bugs.launchpad.net/neutron/+bug/1359523 and is worked on.

tags: added: sg-fw
Changed in neutron:
assignee: nobody → Ann Kamyshnikova (akamyshnikova)
Changed in mos:
assignee: nobody → Ann Kamyshnikova (akamyshnikova)
Changed in mos:
milestone: none → 6.1
Changed in mos:
importance: Undecided → High
Revision history for this message
Aleksandr Shaposhnikov (alashai8) wrote :

Hi Eugene,

I'm just trying to mention that fixing of this bug will also fix issues with isolation.

Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

Well, the issue with tenant networks isolation is orthogonal to the topology.

Revision history for this message
Dmitry Mescheryakov (dmitrymex) wrote :

I've created a separate issue to track the bug in MOS project - https://bugs.launchpad.net/mos/+bug/1434029

no longer affects: mos
Revision history for this message
Kevin Benton (kevinbenton) wrote :

Hi Eugene,

These are slightly different. The other bug is caused by conntrack state being shared. The fix for that (zones) won't fix this. This issue here is caused by rules based on security group members being translated into IP addresses. Those IP addresses might not actually belong to the security group members if they are on a completely different network.

Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

This bug is > 365 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

Changed in neutron:
assignee: Ann Taraday (akamyshnikova) → nobody
status: New → Incomplete
Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.