Public bug reported: When we create different security group logging objects referencing the same port group, they don’t apply as expected, and it is not consistent.
This happens because the Log object relationship to ACLs is “one to many”. In the implementation, in order to modify ACLs, the driver searches for ACLs associated with the log object name. If it’s already associated, it will be skipped. Details: If we create a security group logging object for that logs accepted packets for a single security group, 3 rules set their logging properties (with log == True): "outport == @pg_5f45afc8_cb14_4439_9859_8524a219d477 && ip4 && ip4.src == 0.0.0.0/0 && icmp4" "inport == @pg_5f45afc8_cb14_4439_9859_8524a219d477 && ip6" "inport == @pg_5f45afc8_cb14_4439_9859_8524a219d477 && ip4" # openstack network log create --resource-type security_group --resource test_sg --event ACCEPT test_log_1 After that we create a sec group logging object for dropped packets referencing that same security group, two new acls are added "inport == @neutron_pg_drop && ip", "outport == @neutron_pg_drop && ip", and this will work correctly. # openstack network log create --resource-type security_group --resource test_sg --event DROP test_log_2 If we do it the other way around, first we add the drop object and therefore 5 ACLs get the logging feature set (the same that were listed before), but those related to accepted traffic get a “log: false” property. This property won’t get updated when we create the “accept” log object (because the logging object associated is the previous rule), therefore causing the accepted traffic to not be logged. # openstack network log create --resource-type security_group --resource test_sg --event DROP test_log_1 # openstack network log create --resource-type security_group --resource test_sg --event ACCEPT test_log_2 If we don’t set any specific security group in the security group logging (don't specify the "--resource" property), only the first object we create will be used. # openstack network log create --resource-type security_group --event ACCEPT test_log_1 # openstack network log create --resource-type security_group --event DROP test_log_2 Although I think the existence of multiple network log objects for the same security group is questionable (I cannot think of use cases where it can be useful), I assume that there might be some reason for them to exists, therefore I limit the scope of this bug to just make this co-existence of multiple network log objects work correctly. Taken from Red Hat's Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1988833 ** Affects: neutron Importance: Undecided Assignee: Elvira García Ruiz (elviragr) Status: New ** Changed in: neutron Assignee: (unassigned) => Elvira García Ruiz (elviragr) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1956763 Title: [OVN] Overlapping configuration for security group logging is not applied correctly Status in neutron: New Bug description: When we create different security group logging objects referencing the same port group, they don’t apply as expected, and it is not consistent. This happens because the Log object relationship to ACLs is “one to many”. In the implementation, in order to modify ACLs, the driver searches for ACLs associated with the log object name. If it’s already associated, it will be skipped. Details: If we create a security group logging object for that logs accepted packets for a single security group, 3 rules set their logging properties (with log == True): "outport == @pg_5f45afc8_cb14_4439_9859_8524a219d477 && ip4 && ip4.src == 0.0.0.0/0 && icmp4" "inport == @pg_5f45afc8_cb14_4439_9859_8524a219d477 && ip6" "inport == @pg_5f45afc8_cb14_4439_9859_8524a219d477 && ip4" # openstack network log create --resource-type security_group --resource test_sg --event ACCEPT test_log_1 After that we create a sec group logging object for dropped packets referencing that same security group, two new acls are added "inport == @neutron_pg_drop && ip", "outport == @neutron_pg_drop && ip", and this will work correctly. # openstack network log create --resource-type security_group --resource test_sg --event DROP test_log_2 If we do it the other way around, first we add the drop object and therefore 5 ACLs get the logging feature set (the same that were listed before), but those related to accepted traffic get a “log: false” property. This property won’t get updated when we create the “accept” log object (because the logging object associated is the previous rule), therefore causing the accepted traffic to not be logged. # openstack network log create --resource-type security_group --resource test_sg --event DROP test_log_1 # openstack network log create --resource-type security_group --resource test_sg --event ACCEPT test_log_2 If we don’t set any specific security group in the security group logging (don't specify the "--resource" property), only the first object we create will be used. # openstack network log create --resource-type security_group --event ACCEPT test_log_1 # openstack network log create --resource-type security_group --event DROP test_log_2 Although I think the existence of multiple network log objects for the same security group is questionable (I cannot think of use cases where it can be useful), I assume that there might be some reason for them to exists, therefore I limit the scope of this bug to just make this co-existence of multiple network log objects work correctly. Taken from Red Hat's Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1988833 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1956763/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
