Chapter 20. Logging security group actions
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 oneDROP
log entry for each incoming or outgoing session that is dropped.NoteIf you log dropped traffic on one or more security groups, the Networking service logs dropped traffic on all security groups.
-
ACCEPT
: Log oneACCEPT
log entry for each new session that is allowed by the security group. -
ALL
(drop and accept): Log allDROP
andACCEPT
events. If you do not set –eventACCEPT
or –eventDROP
, the Networking service defaults toALL
.
The Networking service writes all log data to the same file on every Compute node: /var/log/containers/openvswitch/ovn-controller.log
.
20.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.
$ 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 |
If the openstack extension list output does not include the Logging API Extension:
Add
log
to theNeutronPluginExtensions
parameter in an environment file.Example
parameter_defaults: NeutronPluginExtensions: "qos,port_security,log"
-
Run the
openstack overcloud deploy
command and include the core Orchestration templates, environment files, and this environment file.
Additional resources
20.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 groupsg1
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 portsopenstack network log create my-log3 \ --resource-type security_group \ –event ACCEPT
Verify that the log was created:
$ openstack network log list
20.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:
$ openstack network log list
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.
20.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:
$ openstack network log set --disable <log_object_name>
Replace <log_object_name> with the name of the log object.
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.
20.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:
$ 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.
20.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:
$ 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.
20.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
.
20.8. Sample security group log content
Log content includes the following data:
- A timestamp of the packet flow.
-
A status of the flow:
ACCEPT
orDROP
. - 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
20.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:
$ source ~/stackrc
Set the parameters in a custom environment file. For example,
sg-logging.yaml
.Example
parameter_defaults: ... NeutronOVNLoggingRateLimit=450 NeutronOVNLoggingBurstLimit=50
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.ImportantThe 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