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. 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 Source a credentials file that gives you access to the overcloud with the RHOSP admin role. Enter the following command. If the logging service plug-in and extension are configured properly, the output includes the following: If the openstack extension list output does not include the Logging API Extension: Add log to the NeutronPluginExtensions parameter in an environment file. Example 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 Source a credentials file that gives you access to the overcloud with the RHOSP admin role. 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 Example 2: Log ACCEPT events from all security groups on all ports Verify that the log was created: 18.3. Listing and viewing log objects for security groups You can list and view security group log objects. Procedure Source a credentials file that gives you access to the overcloud with the RHOSP admin role. To list all log objects in a project: To view details of a log object: 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 Source a credentials file that gives you access to the overcloud with the RHOSP admin role. To disable a log object, enter the following command: Replace <log_object_name> with the name of the log object. To enable a log object, enter the following command: 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 Source a credentials file that gives you access to the overcloud with the RHOSP admin role. To rename a log object, enter the following command: 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 Source a credentials file that gives you access to the overcloud with the RHOSP admin role. To delete one or more log objects, enter the following command: 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 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 Log in to the undercloud host as the stack user. Source the undercloud credentials file: Set the parameters in a custom environment file. For example, sg-logging.yaml . Example 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

Commands:
openstack network log create my-log1 --resource-type security_group --resource security-group1 --event ACCEPT
openstack extension list --max-width 80 | grep logging
| Logging API Extension | logging | Provides a logging API |
parameter_defaults: NeutronPluginExtensions: "qos,port_security,log"
openstack network log create my-log1 --resource-type security_group --resource sg1 -event ACCEPT
openstack network log create my-log3 --resource-type security_group -event ACCEPT
openstack network log list
openstack network log list
openstack network log show <log_object_name>
openstack network log set --disable <log_object_name>
openstack network log set --enable <log_object_name>
openstack network log set --name <new_log_object_name> <object>
openstack network log delete <log_object_name> [<log_object_name> ...]
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
source ~/stackrc
parameter_defaults: NeutronOVNLoggingRateLimit=450 NeutronOVNLoggingBurstLimit=50
openstack overcloud deploy --templates <core_heat_templates> -e <other_environment_files> -e /home/stack/templates/neutron-ovn-dvr-ha.yaml