CODEWITHSUNDEEP
kubernetesazure-akskubernetes-networkpolicykubernetes-networking
JNK
JNK

Reputation: 836

Kubernetes network policy blocks traffic between nodes on AKS

I am using Azure Kubernetes Service (AKS) and want to make sure pods inside a specific namespace can only receive ingress traffic from other pods in the same namespace.

I found this network policy to achieve this namespace isolation (from here):

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: my-namespace
  name: deny-from-other-namespaces
spec:
  podSelector:
    matchLabels:
  ingress:
  - from:
    - podSelector: {}

After I create this network policy, it successfully blocks traffic between pods on "my-namespace" and another namespace while communication between the pods in "my-namespace" is still possible. However, this is only true if both pods are scheduled on the same node. If both pods are in "my-namespace" but run on different nodes, then the connection between them no longer works. As soon as I delete above network policy, the connection works again. I would think that this is not the intended behavior, as the pods are in the same namespace and ingress traffic should therefore be allowed. Does anybody know what could cause this issue?

I am running Kubernetes version 1.19.6 with kubenet and calico network policies.

Upvotes: 3

Views: 1413

Answers (1)

Nepomucen
Nepomucen

Reputation: 6567

Looks like you hit a known problem in AKS clusters v1.19+ around "Pod IP SNAT/Masquerade behavior".

How it affects clusters using Calico's plugin for Network Policies was explained there by other users:

Just for information of other users, this issue causes problem for a NetworkPolicy with podSelector configs. Since the policy will be set based on the ipset of the pods in the IPtables by Calico, but the source IP of the packet is set to the node IP and even the packets that are supposed to be allowed will be dropped.

Please read more about this problem in github issue #2031, along with the hard fix (node image upgrade) or workaround (run Daemonset creating SNAT exemption in iptables).

Upvotes: 1

Related Questions