yahoo-eng-team team mailing list archive

[Elvira García Ruiz <1956763@xxxxxxxxxxxxxxxxxx>]

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