RFE: Security group rule using address set

[Han Zhou]

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.

[cheng (tangch318)]

Does it any update?

[Armando Migliaccio (armando-migliaccio)]

This is an interesting use case. Worth discussing.

[Kevin Benton (kevinbenton)]

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?

[Han Zhou (zhouhan)]

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

[Kevin Benton (kevinbenton)]

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?

[Kevin Benton (kevinbenton)]

(or do you have time?)

[Han Zhou (zhouhan)]

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.

[Dongcan Ye (hellochosen)]

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

[Kevin Benton (kevinbenton)]

@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.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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.

[Brian Haley (brian-haley)]

Closing as this is very old and the Queens spec was never update/moved to a newer release. Please re-open if anyone intends to work on it further. Thanks.