neutron

RFE: Security group rule using address set

Bug #1649417 reported by Han Zhou
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Triaged
Wishlist
Han Zhou

Bug Description

Today if we want to create a rule in security group to allow access to/from a set of remote IPs, there are 2 ways:

1. If the set of remote IPs belongs to a group of Neutron ports, we can attach those remote Neutron ports to a Neutron security group and use the "remote group" field in security group rule.

2. If the set of remote IPs can't be mapped to Neutron ports (they can be IPs from external or legacy networking system), we will have to white-list each individual IPs (if they cannot be summarized to CIDRs) in each rule that references to that set of IPs in the remote_ip_prefix field.

For 2, if the number of remote IPs is huge, it will be inefficient in Neutron Security group implementation and cause scaling issues. Now that some back-end SDN systems (e.g. OVN) support concept of "address set", it will be good to have same model in Neutron security group, so that the capability of "address set" can be utilized directly for external IPs.

It can be a simple extension to Neutron's Security Group extension, to support "Address Set" object and reference it in Neutron security group rules.

Tags: rfe-approved
Armando Migliaccio (armando-migliaccio)
tags: added: rfe
Changed in neutron:
status: New → Confirmed
importance: Undecided → Wishlist
Dongcan Ye (hellochosen)
Changed in neutron:
assignee: nobody → Dongcan Ye (hellochosen)
Revision history for this message
cheng (tangch318) wrote :

Does it any update?

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

This is an interesting use case. Worth discussing.

Changed in neutron:
status: Confirmed → Triaged
Revision history for this message
Kevin Benton (kevinbenton) wrote :

I think this can be solved using allowed address pairs because they are included in the remote security group calculation.

So you create a dummy port to represent all of your external devices. Then you add each external CIDR as an allowed_address_pair entry to the port. Then that will be included in remote_security_group calculations for SG that allows traffic from that group.

Will that solve your use case?

Revision history for this message
Han Zhou (zhouhan) wrote :

Kevin, thanks for the suggestion. There are problems of this approach:

1. as I remember the limit was 32 pairs for allowed-address-pair in earlier releases, not sure about now. Even the limit is relieved, I wonder if it would scale for large number of IPs (e.g. thousands) for one group.

2. The "pair" requires a MAC, which is not needed here. And if we put a dummy MAC it is still redundant data in the DB. Then I would use a dummy port with many IP addresses on a dummy 0.0.0.0/0 subnet instead.

No matter if using allowed-address-pairs or just ip-addresses for a dummy port, it is like a workaround. Making address-set first class object sounds better and takes not big effort. In fact my colleague already implemented this and it is used in production. It is based on an older neutron release with some legacy code so not ready for opensource yet. It is good to see someone working on this for upstream :)

Revision history for this message
Kevin Benton (kevinbenton) wrote :

It's easy to make the change to add more stuff. The hard part is doing it in a way that doesn't interfere with existing users of the security group API.

Does your colleague have any time to contribute the code upstream?

Revision history for this message
Kevin Benton (kevinbenton) wrote :

(or do you have time?)

Revision history for this message
Han Zhou (zhouhan) wrote :

Kevin, we'd be happy to contribute. Not sure if Dongcan Ye has any progress on it. We don't want to create conflicting work.

Revision history for this message
Dongcan Ye (hellochosen) wrote :

Sorry, I'm not processing this, please assign.

Changed in neutron:
assignee: Dongcan Ye (hellochosen) → nobody
Revision history for this message
Kevin Benton (kevinbenton) wrote :

@Han Zhou,

Please assign yourself an proceed with writing up a spec containing details about how the API will work with the existing SG API. We need to make sure we do this in a back-ward compatible way.

tags: added: rfe-approved
removed: rfe
Han Zhou (zhouhan)
Changed in neutron:
assignee: nobody → Han Zhou (zhouhan)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron-specs (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/515248

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron-specs (master)

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.opendev.org/515248
Reason: According to what we agreed during Shanghai PTG, I abandon this patch for now due to no activity. If You would be interested in continue work on this, feel free to restore the patch.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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