Network Policy Manager merges rules incorrectly #432
Description
Is this a request for help?:
No
Is this an ISSUE or FEATURE REQUEST? (choose one):
ISSUE
Which release version?:
1.0.28
Which component (CNI/IPAM/CNM/CNS):
NPM
Which Operating System (Linux/Windows):
Linux
For Linux: Include Distro and kernel version using "uname -a"
Linux aks-agentpool-34239724-1 4.15.0-1059-azure #64-Ubuntu SMP Fri Sep 13 17:02:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
For windows: provide output of "$(Get-ItemProperty -Path "C:\windows\system32\hal.dll").VersionInfo.FileVersion"
Which Orchestrator and version (e.g. Kubernetes, Docker)
Kubernetes
What happened:
Network policy rules are merged in an unexpected way. Setting up two rules, e.g. egress to ip address 10.0.0.4 on port 80 and egress to 10.0.0.5 on port 443 results in a combination of the two rules being created. The rule applied will allow access to 10.0.0.4 on port 80 and 443 and similarly allow access to 10.0.0.5 on port 80 and 443
What you expected to happen:
The rules should operate independently. Allowing access to a particular port for one destination should not allow access to that port for all destinations.
How to reproduce it (as minimally and precisely as possible):
Create a network policy with two egress destinations, e.g.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: firewall-test
spec:
policyTypes:
- Egress
podSelector:
matchLabels:
app: firewall-test
egress:
- to:
- ipBlock:
cidr: 151.101.192.67/32
ports:
- protocol: TCP
port: 80
- to:
- ipBlock:
cidr: 151.101.128.67/32
ports:
- port: 443
protocol: TCP
(Or create two separate network policies - the behaviour will be the same.)
Run a pod with the label firewall-test that you can try out curl commands in. e.g.
kubectl run -l app=firewall-test -it --image=byrnedo/alpine-curl curl --command sh
From within the pod confirm that you can access both ip addresses specified in the rule on both ports.
curl -kv --resolve "xkcd.com:443:151.101.192.67" https://xkcd.com
curl -kv --resolve "xkcd.com:80:151.101.192.67" http://xkcd.com
curl -kv --resolve "xkcd.com:443:151.101.128.67" https://xkcd.com
curl -kv --resolve "xkcd.com:80:151.101.128.67" http://xkcd.com
The expected behaviour would be for two of those commands to fail but currently they all succeed.
Anything else we need to know:
I suspect that the problem is generic across both ingress and egress and that a similar problem exists for ingress rules, such that allowing access to a port from one source will allow access to that port from any other source specified.