On Fri, Aug 2, 2024 at 12:54 PM Sławek Kapłoński <skaplons@redhat.com> wrote:
Dnia piątek, 2 sierpnia 2024 12:14:40 CEST David Pineau pisze:
In the second case, this leads me to the proposal mentioned in the subject:
Offer a Network/SecurityGroup binding mechanism that would
automatically/implicitly include its rules to the port's rules.
The idea is that this would allow an administrator (and project
administrator?)
to enforce specific rules via security groups attached to the network
itself,
effectively providing a category of network aimed at providing connectivity
to a specific external service.
Additionally, this creates a behavior where unless the administrator allows
it,
no two VMs on this network may be able to communicate together, as a
default.
The way how security groups currently works is that You can specify what kind of traffic is allowed. You can't specify explicilty what is forbidden so even if you would have such additional security group attached to the network and through that effectively to all ports in that network, user would be able to add his own security group to the port and allow traffic which Your "network SG" did not allow.
Whelp, in our experiments, and trying to formulate a solution, we fully overlooked that, thanks for pointing it out.
What do you think about this feature ?
Is there any major risk/flaw that I might be missing ?
Would you, as a community, welcome such an effort ?
I'm not saying I am against such idea but I think this will require very detailed spec with consideration of various corner cases and may be really complicated to do with how currently Neutron has implemented SG in general.
I think You should propose RFE: https://docs.openstack.org/neutron/latest/contributor/policies/blueprints.ht... and it will be then discussed in one of the neutron drivers team meetings. That should be first step for You.
I wasn't sure I should do this without reaching out on the ML first. Thanks for pointing out the flaws of our current proposal. I'll try to revise it for something slightly more fitting to the current neutron design and implementations, then I'll open the RFE to further the discussions.