server: scope IPv6 security group member rules to the exact host - #14037
server: scope IPv6 security group member rules to the exact host#14037nagaboinaramgopal wants to merge 1 commit into
Conversation
wido
left a comment
wido
left a comment
There was a problem hiding this comment.
Code looks good. This is a very common IPv6 oversight of people. Good catch! Lets merge this one quickly
but in the 4.20 branch. by the looks of it this has been in since 4.19.4? |
When a security group rule references another security group, each member VM should be authorized as an exact host. The IPv4 address is correctly pinned to a /32, but the IPv6 address was expanded to /64, opening the whole subnet the member sits in rather than just that member. Pin the IPv6 member to /128 to match the IPv4 behaviour.
I did not check. But lets make sure it at least goes into 4.20 and onwards |
8358dfa to
8c6df72
Compare
|
tnx guys |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 4.20 #14037 +/- ##
============================================
+ Coverage 16.34% 19.78% +3.43%
- Complexity 13574 19992 +6418
============================================
Files 5669 6371 +702
Lines 501368 575899 +74531
Branches 60903 70495 +9592
============================================
+ Hits 81964 113940 +31976
- Misses 410219 449522 +39303
- Partials 9185 12437 +3252
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 |
|
@DaanHoogland 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 19090 |
4 participants
Description
When a security group rule references another security group, each member VM
should be authorized as an exact host. The IPv4 address is correctly pinned to a
/32, but the IPv6 address was expanded to /64, opening the whole subnet the
member sits in rather than just that member. This silently broadens the rule to
every address in the member's /64.
Pin the IPv6 member to /128 to match the IPv4 behaviour.
Types of changes
Feature/Enhancement Scale or Bug Severity
Bug Severity
How Has This Been Tested?
Added a unit test asserting an IPv6 security-group member is authorized as a /128
host and not the whole /64. Also built the standard packages and deployed on a KVM
advanced zone.