prashanthr2 opened a new pull request, #14519:
URL: https://github.com/apache/cloudstack/pull/14519
### 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:
-A FORWARD -o breth1-51 -j DROP
-A FORWARD -i breth1-51 -j DROP
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:
1. `LibvirtComputingResource.applyDefaultNetworkRules()` only calls
`configureDefaultNetworkRulesForSystemVm()` when a nic reports
`isSecurityGroupEnabled()`, and
`NetworkModelImpl.isSecurityGroupSupportedInNetwork()` returns false for
anything that is not
`TrafficType.Guest`. System VMs have only control, management and public
nics.
2. `SecurityGroupManagerImpl.handleVmMigrated()` returned before reaching
the system VM branch,
because `isVmSecurityGroupEnabled()` inspects the VM's own nics.
`NetworkRulesSystemVmCommand`
has exactly one sender in the codebase, this line, so it was dead code.
3. `add_fw_framework()` does not program the system VMs already attached to
a bridge when it
creates the framework there.
### Changes
* `SecurityGroupManagerImpl.handleVmMigrated()` moves the
`isVmSecurityGroupEnabled()` guard into
the user VM branch, so system VMs reach `NetworkRulesSystemVmCommand`.
* `configureDefaultNetworkRulesForSystemVm()` gains an
`onlyExistingFramework` mode which passes
`--onlyexistingframework` to `security_group.py`.
`default_network_rules_systemvm()` then filters
out the bridges with no framework instead of creating one.
* `LibvirtNetworkRulesSystemVmCommandWrapper` uses that mode, as does a new
fallback in
`applyDefaultNetworkRules()` for system VMs with no security group enabled
nic.
* `add_fw_framework()` programs the system VMs already attached to the
bridge at the point the
framework 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
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] New feature (non-breaking change which adds functionality)
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] Enhancement (improves an existing feature and functionality)
- [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
- [ ] build/CI
- [ ] test (unit or integration test code)
### Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [x] Major
- [ ] Minor
- [ ] Trivial
### 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:
1. Start a security grouped instance on host A so `add_fw_framework()`
installs the framework on
the shared/public bridge, then migrate the SSVM onto host A. Before the
change
`BF-<bridge>-OUT` is empty and the SSVM is unreachable; after the change
its vifs are
programmed and it stays reachable.
2. With the SSVM already on host A, start the first security grouped
instance there. The framework
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 no
framework and never creates one.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
