-
Notifications
You must be signed in to change notification settings - Fork 359
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
Add support for NodeNetworkPolicy datapath #5658
Conversation
4dd92cb
to
ed61f70
Compare
621e5a0
to
fa67a44
Compare
3a18e52
to
2b2307f
Compare
2b2307f
to
fafbd00
Compare
fafbd00
to
a69ef99
Compare
a69ef99
to
5c3b084
Compare
port: 22 | ||
``` | ||
|
||
## Limitations |
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.
General question: should we add more clarifications in the limitations section in terms of what it means to have a ipBlock
specified in the ingress block of a node networkpolicy? This could cause a great deal of confusion for users. For example, consider a multi-cluster setup with non-overlapping CIDRs, pod-to-pod connectivity enabled with gateways. In case the node where the policy is applied to is not the gateway node, wouldn't the ingress ipBlock feature not work properly due to the SNAT at the gateway (if the user specify CIDRs from the other clusters)? In addition, out of cluster traffic tend to have similar issues due SNATs at cloud load balancers before they enter Nodes? @tnqn
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.
This is not specific to Node networkpolicy. Even for Pod networkpolicy, SNAT can happen in many cases (lke NodePort traffic), I feel it's not too hard for users to get that if your traffic gets SNATed before reaching the endpoint, the policy will be enforced based on the translated IP. But adding a note to explain the SNAT and IPBlock stuff in https://github.com/antrea-io/antrea/blob/main/docs/antrea-network-policy.md#notes-and-constraints sounds good to me.
c5a8f07
to
d0f3bd5
Compare
912aa68
to
795f130
Compare
795f130
to
783ef52
Compare
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.
LGTM overall, a few nits.
@hongliangl please help to update the PR summary to explain this PR. |
Updated |
45d69c4
to
471948c
Compare
/test-all |
This PR introduces support for the NodeNetworkPolicy datapath, extending Antrea ClusterNetworkPolicy (ACNP). The implementation leverages iptables and ipset for enforcing rules, safeguarding Kubernetes Nodes. There are four key components to implement the data path: - Core iptables rule - Integrated into static chains ANTREA-POL-INGRESS-RULES (ingress) or ANTREA-POL-EGRESS-RULES (egress). - Matches an ipset that includes NodeNetworkPolicy rule source or destination IPs, or directly matches a single IP. - Targets an action or a service chain created for NodeNetworkPolicy rule with multiple services. - Service iptables chain - Created for NodeNetworkPolicy rule with multiple services. - Service iptables rules: - Added to the service chain for NodeNetworkPolicy rule, constructed from rule services. - From/To ipset: - Created for a NodeNetworkPolicy rule, containing source (ingress) or destination (egress) IPs. Example ingress or egress core iptables rules organized by priorities: ``` :ANTREA-POL-INGRESS-RULES -A ANTREA-POL-INGRESS-RULES -m set --match-set ANTREA-POL-RULE1-4 src -j ANTREA-POL-RULE1 -m comment --comment "Antrea: for rule RULE1, policy AntreaClusterNetworkPolicy:name1" -A ANTREA-POL-INGRESS-RULES -m set --match-set ANTREA-POL-RULE2-4 src -p tcp --dport 8080 -j ACCEPT -m comment --comment "Antrea: for rule RULE2, policy AntreaClusterNetworkPolicy:name2" -A ANTREA-POL-INGRESS-RULES -s 3.3.3.3/32 src -j ANTREA-POL-RULE3 -m comment --comment "Antrea: for rule RULE3, policy AntreaClusterNetworkPolicy:name3" -A ANTREA-POL-INGRESS-RULES -s 4.4.4.4/32 -p tcp --dport 80 -j ACCEPT -m comment --comment "Antrea: for rule RULE4, policy AntreaClusterNetworkPolicy:name4" ``` Example service chain (for rule with multiple services):: ``` :ANTREA-POL-RULE1 -A ANTREA-POL-RULE1 -j ACCEPT -p tcp --dport 80 -A ANTREA-POL-RULE1 -j ACCEPT -p tcp --dport 443 ``` Example ipset (for rule with multiple source or destination IPs) ``` Name: ANTREA-POL-RULE1-4 Type: hash:net Revision: 6 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 472 References: 1 Number of entries: 2 Members: 1.1.1.1 1.1.1.2 ``` Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
471948c
to
32e091b
Compare
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.
LGTM
@jianjuns @luolanzone do you have other comments?
/test-all |
I have no extra comment. |
/test-ipv6-all |
/test-conformance |
This PR introduces support for the NodeNetworkPolicy datapath, extending Antrea
ClusterNetworkPolicy (ACNP). The implementation leverages iptables and ipset for
enforcing rules, safeguarding Kubernetes Nodes.
There are four key components to implement the data path:
ANTREA-POL-EGRESS-RULES (egress).
destination IPs, or directly matches a single IP.
rule with multiple services.
rule services.
destination (egress) IPs.
Example ingress or egress core iptables rules organized by priorities:
Example service chain (for rule with multiple services)::
Example ipset (for rule with multiple source or destination IPs)
Signed-off-by: Hongliang Liu lhongliang@vmware.com