← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1956763] Re: [OVN] Overlapping configuration for security group logging is not applied correctly

 

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/822096
Committed: https://opendev.org/openstack/neutron/commit/522837a97f20d1d9325f7d0719811e263d3fd1c3
Submitter: "Zuul (22348)"
Branch:    master

commit 522837a97f20d1d9325f7d0719811e263d3fd1c3
Author: Elvira García <egarciar@xxxxxxxxxx>
Date:   Fri Dec 17 12:29:44 2021 +0100

    [OVN] Fix overlapping security group objects not correctly applied
    
    If a security group object modified an Access Control List in OVN, it
    could not be modified by another object. This change prevents the driver
    from associating more ACLs than needed if the network log object created
    is to log the dropped traffic. Functional tests consider the existence
    of events now.
    
    Closes-Bug: #1956763
    Change-Id: Ib392b46308aaf76386a747870c5600790a268d51


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
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:
  Fix Released

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



References