Chapter 18. Logging security group actions

Note

Logging of security group actions is available in this release as a Technology Preview, and therefore is not fully supported by Red Hat. It should be used only for testing, and should not be deployed in a production environment. For more information about Technology Preview features, see Scope of Coverage Details.

See the following security group logging known issues and workarounds: https://bugzilla.redhat.com/show_bug.cgi?id=2241184 and https://bugzilla.redhat.com/show_bug.cgi?id=2192918.

To monitor traffic flows into and out of a virtual machine (VM) instance, you can create packet logs for security groups. Each log generates a stream of data about packet flow events and appends it to a common log file on the Compute host from which the VM instance was launched.

You can associate any instance port with one or more security groups and define one or more rules for each security group. For example, you can create a rule to allow inbound SSH traffic to any virtual machine in a security group. You can create another rule in the same security group to allow virtual machines in that group to initiate and respond to ICMP (ping) messages.

Then you can create logs to record combinations of packet flow events. For example, the following command creates a log to capture all ACCEPT events in the security group security-group1. 

$ openstack network log create my-log1 \
--resource-type security_group \
--resource security-group1 \
--event ACCEPT

You can create multiple logs to capture data about specific combinations of security groups and packet flow events.

You can configure the following parameters:

resource-type
You must set this required parameter to security_group.
resource (security group names)
You can optionally limit a log to a specific security group with the target argument. For example: --resource security-group1. If you do not specify a resource, the log will capture events from all security groups on the specified ports in the project.
event (types of events to log)

You can choose to log the following packet flow events:

  • DROP: Log one DROP log entry for each incoming or outgoing session that is dropped.

    Note

    If you log dropped traffic on one or more security groups, the Networking service logs dropped traffic on all security groups.

  • ACCEPT: Log one ACCEPT log entry for each new session that is allowed by the security group.
  • ALL (drop and accept): Log all DROP and ACCEPT events. If you do not set –event ACCEPT or –event DROP, the Networking service defaults to ALL.
Note

The Networking service writes all log data to the same file on every Compute node: /var/log/containers/openvswitch/ovn-controller.log.

18.1. Verifying that security group logging is enabled

To prepare your deployment for network packet logging, ensure that the logging service plug-in and logging extension are configured.

Procedure

  1. Source a credentials file that gives you access to the overcloud with the RHOSP admin role.

  2. Enter the following command. 

    $ openstack extension list --max-width 80 | grep logging

    If the logging service plug-in and extension are configured properly, the output includes the following: 

    | Logging API Extension   | logging       | Provides a logging API   |

  3. If the openstack extension list output does not include the Logging API Extension:

    1. Add log to the NeutronPluginExtensions parameter in an environment file.

      Example

      parameter_defaults:
    NeutronPluginExtensions: "qos,port_security,log"

    2. Run the openstack overcloud deploy command and include the core Orchestration templates, environment files, and this environment file.

18.2. Creating log objects for security groups

Create log objects with the resource type security_group.

Prerequisites

  • You have created security groups
  • You have created security group rules for the security groups
  • You have assigned ports to the security groups

Procedure

  1. Source a credentials file that gives you access to the overcloud with the RHOSP admin role.

  2. Create a log by using the openstack network log create command with the appropriate set of arguments.

    Example 1: Log ACCEPT events from the security group sg1 on all ports

    $ openstack network log create my-log1 \
--resource-type security_group \
--resource sg1 \
–event ACCEPT

    Example 2: Log ACCEPT events from all security groups on all ports

    openstack network log create my-log3 \
--resource-type security_group \
–event ACCEPT

  3. Verify that the log was created: 

    $ openstack network log list

18.3. Listing and viewing log objects for security groups

You can list and view security group log objects.

Procedure

  1. Source a credentials file that gives you access to the overcloud with the RHOSP admin role.

  2. To list all log objects in a project: 

    $ openstack network log list

  3. To view details of a log object: 

    $ openstack network log show <log_object_name>

    Replace <log_object_name> with the name of the log object.

18.4. Enabling and disabling log objects for security groups

When you create a log object, it is enabled by default. You can disable or enable a log object.

Procedure

  1. Source a credentials file that gives you access to the overcloud with the RHOSP admin role.

  2. To disable a log object, enter the following command: 

    $ openstack network log set --disable <log_object_name>

    Replace <log_object_name> with the name of the log object.

  3. To enable a log object, enter the following command: 

    $ openstack network log set --enable <log_object_name>

    Replace <log_object_name> with the name of the log object.

18.5. Renaming a log object for security groups

You can change the name of a log object.

Procedure

  1. Source a credentials file that gives you access to the overcloud with the RHOSP admin role.

  2. To rename a log object, enter the following command: 

    $ openstack network log set --name <new_log_object_name> <object>

    Replace <new_log_object_name> with the new name of the log object. Replace <object> with the old name or ID of the log object.

18.6. Deleting a log object for security groups

You can delete log objects.

Procedure

  1. Source a credentials file that gives you access to the overcloud with the RHOSP admin role.

  2. To delete one or more log objects, enter the following command: 

    $ openstack network log delete <log_object_name> [<log_object_name> ...]

    Replace <log_object_name> with the name of the log object to delete. To delete multiple log objects, enter a list of log object names, separated by spaces.

18.7. Accessing security group log content

The Networking service aggregates security group logs from all VM instances on a Compute node in one location on the Compute node host: /var/log/containers/openvswitch/ovn-controller.log.

The log file contains other log objects. Security group log entries include the string acl_log.

18.8. Sample security group log content

Log content includes the following data:

  • A timestamp of the packet flow.
  • A status of the flow: ACCEPT or DROP.
  • An indication of the originator of the flow. For example, which project or log resource generated the events.
  • An identifier of the associated instance interface (Neutron port ID).
  • Layer 2, 3 and 4 information such as MAC, address, port, and protocol.

Example: logged data from an ACCEPT event

2022-11-30T03:29:12.868Z|00111|acl_log(ovn_pinctrl1)|INFO|name="neutron-bc53f8df-2318-4d08-8e12-89e92b08deec", verdict=allow, severity=info, direction=from-lport: udp,vlan_tci=0x0000,dl_src=fa:16:3e:70:c4:45,dl_dst=fa:16:3e:66:8b:18,nw_src=192.168.100.59,nw_dst=192.168.100.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=68,tp_dst=67

18.9. Adjusting rate and burst limits for security group logging

To avoid overwhelming the control plane with the transmission of logging data, the Networking service sets limits on the maximum number of packets logged per second. You can change this limit using the NeutronOVNLoggingRateLimit parameter.

When logging packet transmission reaches the rate limit, the Networking service queues the excess packets to be logged. You can change the maximum number of queued packets using the NeutronOVNLoggingBurstLimit parameter.

The default values are NeutronOVNLoggingRateLimit:100 packets per second and NeutronOVNLoggingBurstLimit:25 packets in queue. These are also the minimum required values. The limits do not operate correctly with lower values.

Logging rate and burst limits do not limit control of data traffic. They limit only the transmission of logging data.

Procedure

  1. Log in to the undercloud host as the stack user.

  2. Source the undercloud credentials file: 

    $ source ~/stackrc

  3. Set the parameters in a custom environment file. For example, sg-logging.yaml.

    Example

    parameter_defaults:
...
    NeutronOVNLoggingRateLimit=450
    NeutronOVNLoggingBurstLimit=50

  4. Run the deployment command and include the core Heat templates, other environment files, and the custom roles data file in your deployment command with the -r option.

    Important

    The order of the environment files is important because the parameters and resources defined in subsequent environment files take precedence.

    Example

    $ openstack overcloud deploy --templates <core_heat_templates> \
-e <other_environment_files> \
-e /home/stack/templates/neutron-ovn-dvr-ha.yaml