NetworkPolicy tests for blocking north/south traffic #114369

Activity

1. k8s-ci-robot commented on Dec 8, 2022

   

   k8s-ci-robot

   on Dec 8, 2022

   Contributor

   More actions

   @danwinship:
   This request has been marked as suitable for new contributors.

   Guidelines

   Please ensure that the issue body includes answers to the following questions:

   • Why are we solving this issue?
   • To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
   • Does this issue have zero to low barrier of entry?
   • How can the assignee reach out to you for help?

   For more details on the requirements of such an issue, please see here and ensure that they are met.

   If this request no longer meets these requirements, the label can be removed
   by commenting with the /remove-good-first-issue command.

   Details

   In response to this:

   The NP docs point out that NP's semantics for north/south traffic are not very clearly defined:

   Cluster ingress and egress mechanisms often require rewriting the source or destination IP of packets. In cases where this happens, it is not defined whether this happens before or after NetworkPolicy processing, and the behavior may be different for different combinations of network plugin, cloud provider, Service implementation, etc.

   In the case of ingress, this means that in some cases you may be able to filter incoming packets based on the actual original source IP, while in other cases, the "source IP" that the NetworkPolicy acts on may be the IP of a LoadBalancer or of the Pod's node, etc.

   For egress, this means that connections from pods to Service IPs that get rewritten to cluster-external IPs may or may not be subject to ipBlock-based policies.

   However, what's not ambiguous is that a pod which is fully isolated for ingress should not accept E/W or N/S traffic. Regardless of how the ingress/LB/cloud handles the traffic, it should end up getting blocked. (Well, unless it gets masqueraded to the pod's node IP, because then it hits that exception to the rules.)

   Unfortunately we can't say the same for egress; I think we assume that a pod-to-service-IP connection will be allowed to reach kube-proxy even if the pod is fully isolated-for-egress, but we explicitly don't require that ipBlock policies get applied after service proxying.

   Anyway, we should be able to add a test to test/e2e/network/netpol/network_policy.go that confirms that cluster-ingress traffic to a fully isolated-for-ingress pod is not allowed. In particular, if we create a LoadBalancer Service with externalTrafficPolicy: Local, and a NetworkPolicy blocking all ingress to that Service's Pods, then we should not be able to connect to the service via either the LoadBalancer IP/name or via its NodePort (on one of the correct nodes).

   /sig network
   /area network-policy
   /priority backlog
   /help
   /good-first-issue

   Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
2. k8s-ci-robot

   added

   sig/networkCategorizes an issue or PR as relevant to SIG Network.Categorizes an issue or PR as relevant to SIG Network.

   good first issueDenotes an issue ready for a new contributor, according to the "help wanted" guidelines.Denotes an issue ready for a new contributor, according to the "help wanted" guidelines.

   area/network-policyIssues or PRs related to Network Policy subprojectIssues or PRs related to Network Policy subproject

   priority/backlogHigher priority than priority/awaiting-more-evidence.Higher priority than priority/awaiting-more-evidence.

   help wantedDenotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.

   needs-triageIndicates an issue or PR lacks a `triage/foo` label and requires one.Indicates an issue or PR lacks a `triage/foo` label and requires one.

   on Dec 8, 2022
3. thockin

   added

   triage/acceptedIndicates an issue or PR is ready to be actively worked on.Indicates an issue or PR is ready to be actively worked on.

   and removed

   needs-triageIndicates an issue or PR lacks a `triage/foo` label and requires one.Indicates an issue or PR lacks a `triage/foo` label and requires one.

   on Dec 8, 2022
4. thockin

   assigned

   astoycos

   on Dec 8, 2022
5. MohnishMishra commented on Dec 28, 2022

   

   MohnishMishra

   on Dec 28, 2022

   More actions

   Hello, I am Mohnish Mishra. I am a 2nd year student in BTech in Computer Science and Engineering.
   I am new to open-source coding and trying understand the same.
   I am interested in contributing to this project.
   If you could please guide me on what is to be done and what are the pre-requisites for the same, it will be of great help.
6. sftim commented on Dec 29, 2022

   

   sftim

   on Dec 29, 2022

   Contributor

   More actions

   @danwinship this feels to me like an issue that (right now) justifies the help label, but maybe not good-first-issue. WDYT?
7. astoycos commented on Jan 2, 2023

   

   astoycos

   on Jan 2, 2023

   Contributor

   More actions

   This has been on my TODO list, and I'm hoping to either get to it early in the new year or have a member of the network policy api subgroup tackle this. @MohnishMishra Feel free to come to that meeting to learn more :) [Note we are changing the time this year see this pr and slack conversation for more information]

   But yeah @sftim I'd say this is slightly above good first issue :)
8. farahInTheZone commented on Jan 3, 2023

   

   farahInTheZone

   on Jan 3, 2023

   More actions

   Hey. If this is not being actively worked on, I would like to pick this up.
9. MohnishMishra commented on Jan 4, 2023

   

   MohnishMishra

   on Jan 4, 2023

   More actions

   Thank you @astoycos.
   I have joined the mailing group and hope to join the meetings and learn.
   Thank you for the opportunity.
10. 47 remaining items

    Load more

11. kunalworldwide commented on May 26, 2026

    

    kunalworldwide

    on May 26, 2026

    More actions

    @danwinship before I open a new PR — @aroradaman raised whether this should go in network-policy-api instead of test/e2e/network/netpol/network_policy.go. This is a v1 NetworkPolicy test so my assumption is it stays in netpol/, but wanted to check before putting work into the wrong place.

    Also want to confirm I'm reading your latest comments right: the test should create a pod with deny-all-ingress, expose it via NodePort with externalTrafficPolicy: Local, connect from the e2e host (not from inside a pod), and just fail if the connection succeeds. No SNAT detection needed. Should I include a LoadBalancer variant too or keep it narrow for now?
12. danwinship commented on May 26, 2026

    

    danwinship

    on May 26, 2026

    ContributorAuthor

    More actions

    @kunalworldwide there is already a PR open adding a test for this. It just hasn't merged yet.

    👍React with 👍1Reacted by Kunal Das

    👀React with 👀1Reacted by Kunal Das
13. kunalworldwide commented on Jun 29, 2026

    

    kunalworldwide

    on Jun 29, 2026

    More actions

    @danwinship good to know — is the open PR #137390, or a different one? I saw #137390 was closed earlier; if there is a replacement PR it would be useful to link it here so others do not duplicate the work. Happy to help review or test if it is stuck on something.
14. danwinship commented on Jun 29, 2026

    

    danwinship

    on Jun 29, 2026

    ContributorAuthor

    More actions

    There have been multiple PRs opened at various points; you can see them all in the sidebar on the right. One of them is currently open.
15. kunalworldwide commented on Jul 15, 2026

    

    kunalworldwide

    on Jul 15, 2026

    More actions

    @danwinship thanks — I see the open PR now. Is it stuck on anything specific (review bandwidth, rebase, or a design question)? Happy to help review or run the e2e tests if that unblocks it.
16. sanyamk23

    added 10 commits that reference this issue on Aug 31, 2026

    Add e2e test for NetworkPolicy with LoadBalancer Local externalTraffi…

    ...

    This issue will close once commit c47de13 is merged into the 'master' branch.

    c47de13

    Add e2e test for NetworkPolicy with LoadBalancer Local externalTraffi…

    ...

    This issue will close once commit 26fc39e is merged into the 'master' branch.

    26fc39e

    test: add e2e test for NetworkPolicy blocking LoadBalancer Local ingress

    ...

    This issue will close once commit 5705278 is merged into the 'master' branch.

    5705278

    test: add e2e test for NetworkPolicy blocking LoadBalancer Local ingress

    ...

    This issue will close once commit f043edc is merged into the 'master' branch.

    f043edc

    test: add e2e test for netpol LB externalTrafficPolicy

    ...

    This issue will close once commit 7de6fab is merged into the 'master' branch.

    7de6fab

    test: add e2e test for netpol with LB Local

    ...

    This issue will close once commit f796ce5 is merged into the 'master' branch.

    f796ce5

    test: add e2e test for netpol with LB Local

    ...

    This issue will close once commit 245e938 is merged into the 'master' branch.

    245e938

    test: add e2e test for NetworkPolicy blocking LoadBalancer Local ingress

    ...

    This issue will close once commit 9c3b2d0 is merged into the 'master' branch.

    9c3b2d0

    test: add e2e test for netpol with LB Local

    ...

    This issue will close once commit 87fee81 is merged into the 'master' branch.

    87fee81

    test: add e2e test for netpol with LB Local

    ...

    This issue will close once commit 2fe970d is merged into the 'master' branch.

    2fe970d