Repository navigation
kvm: program system VMs into the security group bridge firewall framework - #14519
prashanthr2 wants to merge 3 commits into
Conversation
boring-cyborg
Bot
added
component:kvm
component:networking
component:security-group
Python
…work When a shared security group network and the public network use the same vlan on the same physical device they resolve to the same bridge. The first security grouped instance on a host installs the bridge firewall framework there, including the catch-all FORWARD DROP rules, but the SSVM and CPVM on that same bridge are never programmed into it and lose all new inbound flows. handleVmMigrated() returned before reaching the system VM branch, since isVmSecurityGroupEnabled() inspects the VM's own nics and is only meaningful for user VMs, which made NetworkRulesSystemVmCommand dead code. applyDefaultNetworkRules() likewise skips system VMs in an advanced zone, as none of their nics is security group enabled. System VM rules are now applied on migration and on start, and the system VMs already attached to a bridge are programmed when the framework is created on it. None of the new call sites creates a bridge firewall framework where one does not already exist. Fixes: apache#14518
a570a7c to
a81187a
Compare
|
@blueorangutan package |
|
@ingox a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
@DaanHoogland I'll test it. |
|
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 19808 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.22 #14519 +/- ##
=========================================
Coverage 18.31% 18.31%
- Complexity 16633 16641 +8
=========================================
Files 5939 5939
Lines 537748 537755 +7
Branches 65924 65926 +2
=========================================
+ Hits 98472 98497 +25
+ Misses 428070 428047 -23
- Partials 11206 11211 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@blueorangutan package |
|
@ingox a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 19814 |
|
@blueorangutan package |
|
@ingox a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 19827 |
|
@blueorangutan package |
|
@nvazquez a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19829 |
Description
Fixes: #14518
In an advanced zone with security groups, when a shared guest network uses the same vlan on the
same physical device as the public network, both resolve to the same bridge. The first security
grouped instance on a host installs the bridge firewall framework on that bridge, including:
The SSVM and CPVM have their public nics on the same bridge but are never programmed into the
framework, so every new inbound flow to them is dropped. Established connections survive only
while they remain in conntrack via the RELATED,ESTABLISHED rule, which is why it looks like it
works for a while and then breaks.
Three gaps combine:
LibvirtComputingResource.applyDefaultNetworkRules()only callsconfigureDefaultNetworkRulesForSystemVm()when a nic reportsisSecurityGroupEnabled(), andNetworkModelImpl.isSecurityGroupSupportedInNetwork()returns false for anything that is notTrafficType.Guest. System VMs have only control, management and public nics.SecurityGroupManagerImpl.handleVmMigrated()returned before reaching the system VM branch,because
isVmSecurityGroupEnabled()inspects the VM's own nics.NetworkRulesSystemVmCommandhas exactly one sender in the codebase, this line, so it was dead code.
add_fw_framework()does not program the system VMs already attached to a bridge when itcreates the framework there.
Changes
SecurityGroupManagerImpl.handleVmMigrated()moves theisVmSecurityGroupEnabled()guard intothe user VM branch, so system VMs reach
NetworkRulesSystemVmCommand.configureDefaultNetworkRulesForSystemVm()gains anonlyExistingFrameworkmode which passes--onlyexistingframeworktosecurity_group.py.default_network_rules_systemvm()then filtersout the bridges with no framework instead of creating one.
LibvirtNetworkRulesSystemVmCommandWrapperuses that mode, as does a new fallback inapplyDefaultNetworkRules()for system VMs with no security group enabled nic.add_fw_framework()programs the system VMs already attached to the bridge at the point theframework is created, covering the system VM that arrives before the first user VM.
The only code paths that can create a bridge firewall framework are the ones that create it today.
In zones without security groups no bridge ever has one, so the new call sites return early and
nothing changes.
Types of changes
Bug Severity
How Has This Been Tested?
Unit test added for the
handleVmMigrated()change.Manual, advanced zone with security groups on KVM, shared network and public network on the same
vlan and physical device:
add_fw_framework()installs the framework onthe shared/public bridge, then migrate the SSVM onto host A. Before the change
BF-<bridge>-OUTis empty and the SSVM is unreachable; after the change its vifs areprogrammed and it stays reachable.
is created and the SSVM is programmed in the same pass.
The case where the shared network uses a different vlan from the public network, so the public
bridge has no bridge firewall framework, has not been tested in a lab. By inspection the new call
sites return early there, as
default_network_rules_systemvm()filters out bridges with noframework and never creates one.