Aahan Singh:
Hi everyone,
I had a question regarding network policies.
Let’s say we have 2 pods A and B. We want to setup an egress policy on pod B to allow only tcp connections to pod A. Both pods also have svc called svc-a and svc-b of type cluster ip on ports 6000 and 8000 respectively.
If we implement the egress network policy like so
egress:
-to
-podSelector:
matchLabels:
run: pod-a
Things work just fine. Pod B is able to query pod A using curl svc-a:6000 .But if it’s like so
egress:
-to
-podSelector:
matchLabels:
run: pod-a
ports:
- port: 6000
protocol: TCP
This doesnt work. Querying pod A using curl svc-a:6000 . I use port 6000 because the svc-a is running on port 6000.
Why does this happen?
Abdul Majid:
use run: pod-a instead of run=pod-a
Aahan Singh:
Oo my bad.
Fixed
My question was does using the pod selector as well as the port on which the svc runs block connections to the svc?
Madhan Kumar:
can you try curl directly to the pod ip instead of servicename ? , may be the dns resolution from pod-b gets blocked once you enable egress only to port 6000.
Fernando Jimenez:
You have to allow outbound traffic for name resolution. Also the port 6000 should be target-port of the container, instead of the service, unless both are 6000. There must be a space between a dash for a list and the attribute name. -to: should be - to: same for - podSelector:
Perhaps, this will work?
egress:
- to:
- podSelector:
matchLabels:
run: pod-a
ports:
- port: <targe-port>
protocol: TCP
- to:
ports:
- protocol: TCP
port: 53
- protocol: UDP
port: 53
Aahan Singh:
Awesome @Fernando Jimenez . Thanks for the help. I was using the wrong port. Indeed i needed to use the port 80(one that pod-a exposes) rather than 6000 (what the svc exposes) . After changing that i was able to successfully use curl. Thanks for adding the part about dns name resolution. With your snippet above i was able to get things to run. 
Aahan Singh:
@Madhan Kumar indeed the dns resolution got blocked because i had not allowed comms on port 53 for tcp and udp