Introduction to OpenStack security groups and Conntrack

Security groups in OpenStack implement communication between virtual machines that trust each other, and the same security policy is used by the virtual machines that bind the same security group. The scope of a security group is on a virtual machine, more specifically, on a virtual machine's port rather than on a network. The security group in OpenStack is based on the iptables implementation, because the current openvswitch (OVS) cannot use iptables rule, so the virtual machine connects to the Linux bridge before connecting to the OvS Bridge. Reference link [1].

When using iptables, the status of the message can be categorized as four types: NEW establisedrelated invaild. NetFilter is the connection tracking through the conntrack. Conntrack is a kernel module of Linux and uses the Conntrack entry to record the status of the connection, for reference [2].

1. SG without Conntrack-tool

Figure 1

Neutron initial implementation of the security group function did not consider the processing of conntrack, which led to some problems. 1 Virtual machine vm1 (1.1.1.8) vm2 (1.1.1.9) belongs to the same subnet, which is located in the same compute node, is bound to the default security group, and performs a vm1 ping vm2 to ping. [3] The ingress rule in the default security group is deleted and the egress rule is retained, and vm1 Ping vm2 is found to be still uninterrupted.

The reason for this is that ICMP packets arrive at the iptables processing stage when they reach the vm2 connected Linux bridge. The I-chain corresponding to the vm2 in the Iptables (reference [4]) has a rule of-mstate--state related,established-m comment-j RETURN (Default rule), which indicates a status of related Established connections can flow into the vm2.

Since the ingress rule was removed, neutron did not perform any action on the Conntrack, and there was no action to stop vm1 Ping vm2, and the corresponding Conntrack entry persisted and would not expire. Therefore, even if the ingress rule has been deleted in the default security group, communication is still not interrupted.

$ sudo conntrack-l-p ICMP

ICMP 1 src=1.1.1.8 dst=1.1.1.9 type=8 code=0 id=11521 src=1.1.1.9dst=1.1.1.8 type=0 code=0 id=11521 mark=0 use=1

Conntrack v1.4.1 (conntrack-tools): 1 flowentries have been shown.

If you re-execute VM1 Ping vm2 at this point, you will not be able to ping this time. This message will still be processed into iptables because the default security group has removed the ingress rule, so the condition that the ICMP packets can flow into the vm2 is still to be able to satisfy the state of related,established.

This time, however, the ICMP message is considered a new state. View Conntrack found that although the old entry (ID 11521) still exists, the process of re-pinging is considered a new connection, corresponding to the new entry (ID 12033), unreplied indicates that the connection is not yet established.

$ sudo conntrack-l-p ICMP

ICMP 1 src=1.1.1.8 dst=1.1.1.9 type=8 code=0 id=11521 src=1.1.1.9dst=1.1.1.8 type=0 code=0 id=11521 mark=0 use=1

ICMP 1 src=1.1.1.8 dst=1.1.1.9 type=8 code=0 id=12033 [unreplied]src=1.1.1.9 dst=1.1.1.8 type=0 code=0 id=12033 Mark =0 use=1

Conntrack v1.4.1 (conntrack-tools): 2 flowentries have been shown.

In addition, there is no tenant isolation problem with conntrack processing: Tenant 1 creates virtual machine vm1 (1.1.1.8) vm2 (1.1.1.9), 1, tenant 2 creates a virtual machine with the same IP vm3 (1.1.1.8) vm4 (1.1.1.9) and vm1/2/ 3/4 are all in the same compute node, the Conntrack entry generated by VM1/2 communication will have an impact on the communication between VM3/4, refer to [5].

2. SG with Conntrack-tool

The related bug was raised in 2014, until August 2015, when these issues were resolved. The Stableliberty version uses the Conntrack tool to implement the management of the conntrackentry.

Still using the environment shown in Figure 1, the default security group ingress and egress rules are present when you perform VM1 ping vm2 and view Conntrack:

$ sudo conntrack-l-p ICMP

ICMP 1 src=1.1.1.8 dst=1.1.1.9 type=8 code=0 id=10753 src=1.1.1.9dst=1.1.1.8 type=0 code=0 id=10753 mark=0 zone= 2use=1

Conntrack v1.4.1 (conntrack-tools): 1 flowentries have been shown.

When the ingress rule is removed, the communication is immediately interrupted because the Conntrack entry is immediately deleted.

In addition, the above Conntrack entry adds a zone attribute, which is designed to avoid tenant isolation issues that occur in [5]. On each compute node, the network that the virtual machine belongs to has a one by one correspondence with the local VLAN, the zone value is set to the local VLAN, and the local tenant isolation of the Conntrack entry is implemented.

Reference Links:

[1]https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_openstack_platform/4/html/ Configuration_reference_guide/section_networking-scenarios.html

[2]http://www.iptables.info/en/connection-state.html

[3]https://bugs.launchpad.net/neutron/+bug/1335375

[4]http://blog.csdn.net/yeasy/article/details/21612151?utm_source=tuicool&utm_medium=referral

[5]https://bugs.launchpad.net/neutron/+bug/1359523

Introduction to OpenStack security groups and Conntrack