Change:
ValidateOrFail(k8s, model, &TestCase{FromPort: 81, ToPort: 81, Protocol: v1.ProtocolTCP, Reachability: reachabilityPort81}) }) <ins> ginkgo.It("should support denying of egress traffic on the client side (even if the server explicitly allows this traffic) [Feature:NetworkPolicy]", func() { // x/a --> y/a and y/b // Egress allowed to y/a only. Egress to y/b should be blocked // Ingress on y/a and y/b allow traffic from x/a // Expectation: traffic from x/a to y/a allowed only, traffic from x/a to y/b denied by egress policy nsX, nsY, _, model, k8s := getK8SModel(f) // Building egress policy for x/a to y/a only allowedEgressNamespaces := &metav1.LabelSelector{ MatchLabels: map[string]string{ "ns": nsY, }, } allowedEgressPods := &metav1.LabelSelector{ MatchLabels: map[string]string{ "pod": "a", }, } egressPolicy := GetAllowEgressByNamespaceAndPod("allow-to-ns-y-pod-a", map[string]string{"pod": "a"}, allowedEgressNamespaces, allowedEgressPods) CreatePolicy(k8s, egressPolicy, nsX) // Creating ingress policy to allow from x/a to y/a and y/b allowedIngressNamespaces := &metav1.LabelSelector{ MatchLabels: map[string]string{ "ns": nsX, }, } allowedIngressPods := &metav1.LabelSelector{ MatchLabels: map[string]string{ "pod": "a", }, } allowIngressPolicyPodA := GetAllowIngressByNamespaceAndPod("allow-from-xa-on-ya-match-selector", map[string]string{"pod": "a"}, allowedIngressNamespaces, allowedIngressPods) allowIngressPolicyPodB := GetAllowIngressByNamespaceAndPod("allow-from-xa-on-yb-match-selector", map[string]string{"pod": "b"}, allowedIngressNamespaces, allowedIngressPods) CreatePolicy(k8s, allowIngressPolicyPodA, nsY) CreatePolicy(k8s, allowIngressPolicyPodB, nsY) // While applying the policies, traffic needs to be allowed by both egress and ingress rules. // Egress rules only // 	xa	xb	xc	ya	yb	yc	za	zb	zc // xa	X	X	X	.	*X*	X	X	X	X // xb	.	.	.	.	.	.	.	.	. // xc	.	.	.	.	.	.	.	.	. // ya	.	.	.	.	.	.	.	.	. // yb	.	.	.	.	.	.	.	.	. // yc	.	.	.	.	.	.	.	.	. // za	.	.	.	.	.	.	.	.	. // zb	.	.	.	.	.	.	.	.	. // zc	.	.	.	.	.	.	.	.	. // Ingress rules only // 	xa	xb	xc	ya	yb	yc	za	zb	zc // xa	.	.	.	*.*	.	.	.	.	. // xb	.	.	X	X	.	.	.	.	. // xc	.	.	X	X	.	.	.	.	. // ya	.	.	X	X	.	.	.	.	. // yb	.	.	X	X	.	.	.	.	. // yc	.	.	X	X	.	.	.	.	. // za	.	.	X	X	.	.	.	.	. // zb	.	.	X	X	.	.	.	.	. // zc	.	.	X	X	.	.	.	.	. // In the resulting truth table, connections from x/a should only be allowed to y/a. x/a to y/b should be blocked by the egress on x/a. // Expected results // 	xa	xb	xc	ya	yb	yc	za	zb	zc // xa	X	X	X	.	*X*	X	X	X	X // xb	.	.	.	X	X	.	.	.	. // xc	.	.	.	X	X	.	.	.	. // ya	.	.	.	X	X	.	.	.	. // yb	.	.	.	X	X	.	.	.	. // yc	.	.	.	X	X	.	.	.	. // za	.	.	.	X	X	.	.	.	. // zb	.	.	.	X	X	.	.	.	. // zc	.	.	.	X	X	.	.	.	. reachability := NewReachability(model.AllPods(), true) // Default all traffic flows. // Exception: x/a can only egress to y/a, others are false // Exception: y/a can only allow ingress from x/a, others are false // Exception: y/b has no allowed traffic (due to limit on x/a egress) reachability.ExpectPeer(&Peer{Namespace: nsX, Pod: "a"}, &Peer{}, false) reachability.ExpectPeer(&Peer{}, &Peer{Namespace: nsY, Pod: "a"}, false) reachability.ExpectPeer(&Peer{Namespace: nsX, Pod: "a"}, &Peer{Namespace: nsY, Pod: "a"}, true) reachability.ExpectPeer(&Peer{}, &Peer{Namespace: nsY, Pod: "b"}, false) ValidateOrFail(k8s, model, &TestCase{FromPort: 81, ToPort: 80, Protocol: v1.ProtocolTCP, Reachability: reachability}) }) </ins> ginkgo.It("should enforce egress policy allowing traffic to a server in a different namespace based on PodSelector and NamespaceSelector [Feature:NetworkPolicy]", func() { nsX, nsY, _, model, k8s := getK8SModel(f) allowedNamespaces := &metav1.LabelSelector{

Discussion:
In reference to conversation on #sig-network-policy-api.  What would you like to be : Add a test to the netpol validation framework to validate a scenario where traffic between two pods has egress and ingress rules defined. Why is this needed: To ensure consistent behavior between different implementations of networkPolicy. For example, describes different behavior between Calico networkPolicy and Azure networkPolicy
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig sig-network
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig sig-network Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig network
thanks for offering to hack on this
/sig network
cc
I reviewed the current networkpolicy tests, and I believe this case is already captured in the currents tests.
Thanks for digging into this ... so Your case, yesterday was more then just combining egress and ingress. Your case , was one where Egress blocked a traffic that was allowed by other rules. Which is quite interesting and confuses alot of people. ... It highlights the 'podselector centric' nature of policies.... I think you want to do , right? In that case, Egress rule is specifically created that disallows but Ingress rules explicitly allow And the result is that Egress wins, and traffic is blocked ...
This is an interesting test case, I'd be happy to hack on this and look at adding a table-driven netpol test case but don't want to step on your toes if you're already looking into ! Definitely see the value of illuminating this corner case with a clear test scenario!
Thx for the feedback. You are right that it's still a different case. : I'm looking at what I can throw together today. Stay tuned, and would love your input.
I created the initial version of the test.

The code (and comments) are likely a bit verbose at this point. Should I open a PR against this repo now, or do you want me to make changes to that code prior to the PR?
Looks awesome, I'd go ahead with the PR!
can you reference this issue in your new PR ?
/assign