-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle overlaps in except and allow CIDRs #344
base: main
Are you sure you want to change the base?
Conversation
Can you also add a test case for this in our integration suite? |
@@ -856,10 +857,7 @@ func mergeDuplicateL4Info(ports []v1alpha1.Port) []v1alpha1.Port { | |||
func (l *bpfClient) computeMapEntriesFromEndpointRules(firewallRules []EbpfFirewallRules) (map[string][]byte, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As an enhancement, could you document the behavior of this function as function doc string itself. We pack a lot inside the function here.
@@ -201,7 +201,8 @@ int handle_egress(struct __sk_buff *skb) | |||
return BPF_DROP; | |||
} | |||
|
|||
if ((trie_val->protocol == ANY_IP_PROTOCOL) || (trie_val->protocol == ip->protocol && | |||
if ((trie_val->protocol == ANY_IP_PROTOCOL && ((trie_val->start_port == ANY_PORT) || (l4_dst_port == trie_val->start_port) || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Enhancement Request: We can format this and explain the behavior of in the comment.
a) match any problem and ensure either destination port matches or falls within the range.
@@ -175,31 +175,18 @@ func TestBpfClient_IsEBPFProbeAttached(t *testing.T) { | |||
} | |||
} | |||
|
|||
func TestBpfClient_CheckAndDeriveCatchAllIPPorts(t *testing.T) { | |||
func TestBpfClient_CheckAndDeriveL4InfoFromAnyMatchingCIDRs(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need more test cases here that will cover for the scenarios described in the description of the PR are handled by the test case.
192.168.0.0/16 - allow on port 3306. This is part of 0.0.0.0/0, so check if it is part of any except under this cidr. If yes do not add ports of 0.0.0.0/0 to 192.168.0.0/16. If no, add ports.
Handle all except at end. For every except key, check if entry is already present in cidrsMap. If yes, there is some explicit allow and everything else will be default deny so no change required. If no, we need to add deny all entry to make sure we deny all traffic and do not allow it if it is part of some other superset CIDR
The code change and the logic looks good to me. As noted in the review of the design doc, I wanted to see if there is any simpler way, but handling all except at the end looks alright.
Coverage with test case can help us push this PR to finish line here. Thank you.
Issue #, if available:
If there is an overlap of IPs in an allow rule and in an except block of other rule, we do not handle the merging
Description of changes:
Example:
Before this change we evaluate this as
The correct behavior for 192.168.0.0/16 should be allow on 3306 as explicit allow takes precedence and deny on rest all ports due to except
New evaluation logic - all except blocks are handled at end
Other Changes in the PR:
Testing done with multiple cases of except overlaps
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.