-
Notifications
You must be signed in to change notification settings - Fork 39.4k
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
NetworkPolicy tests for blocking north/south traffic #114369
Comments
@danwinship: GuidelinesPlease ensure that the issue body includes answers to the following questions:
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 In response to this:
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. |
Hello, I am Mohnish Mishra. I am a 2nd year student in BTech in Computer Science and Engineering. |
@danwinship this feels to me like an issue that (right now) justifies the help label, but maybe not good-first-issue. WDYT? |
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 :) |
Hey. If this is not being actively worked on, I would like to pick this up. |
Thank you @astoycos. |
If there is no active development here, I'd like to take it up! |
Hy, I'm Nag, im new to this, i'd like to contribute to this open source i don't know from where to start. could you help me guys. |
/assign @daman1807 who has been very active in the KPNG community and is going to pick this up :) thanks! |
@astoycos: GitHub didn't allow me to assign the following users: daman1807. Note that only kubernetes members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. In response to this:
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. |
/assign |
/assign |
@Daman if you use metallb you can directly implement 9 services, for the 9 pods in the reachability matrix, and then poll them all using dans idea |
looking at this test w/ daman, it seems like an interesting test, but it seems extremely dependent on the infrastructure provider ... i wonder if maybe we should define it in some way as a "networking integration" test, and run it on specific setups - i.e. maybe where the e2e thing is running outside of the cluster, and so on.... ? (https://github.com/kubernetes/test-infra). .... or maybe im overthinking it.... |
How so? If both LoadBalancers and NetworkPolicy are available, then it must be the case that LoadBalancer traffic is blocked when there is a NetworkPolicy blocking all ingress. (Unless the LoadBalancer ingress path ends up SNATting traffic to the pod's node IP, hence the use of |
If u try to access an external service of type LB from a node... the kube proxy will iirc actually not go through the LB and cheat going straight to the pod... In our e2es since usually we run the test from a pod ... the kube proxy impl therefore I think maybe is the thing being tested just as much as the netpol impl But I guess we could add these tests. In general I guess I'd wonder what the "right" way to run them is: would users wanna run em outside the cluster to test the realistic data path that flows from service LB into the pool? |
The LoadBalancer e2e tests, in general, connect from the host running |
let me work on this issue now please |
Ok....this feels like a loadbalancer e2e more then a netpol one but either way works .... let's just make sure we log that it must be run from outside a pod to be meaningful |
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
/triage accepted |
/remove-label good-first-issue |
@astoycos: The label(s) In response to this:
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-sigs/prow repository. |
The NP docs point out that NP's semantics for north/south traffic are not very clearly defined:
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 withexternalTrafficPolicy: 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
The text was updated successfully, but these errors were encountered: