Does NetworkPolicies in K3s (with Kuberouter) supporting external Networktraffic?

[janbaer]

I'm trying to configure a Networkpolicy that should block Network-traffic from a specific external IP-address.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-requests-from-internal-api-only
  namespace: verbu-22164
spec:
  podSelector:
    matchLabels:
      role: service
  policyTypes:
    - Ingress
  ingress:
    - from:
      - ipBlock:
        cidr: 10.2.201.0/24
        except:
          - 10.2.201.113/32

So the Network-range I specified here, is not the IP-range that is used internally in the K3s cluster, but in the network where also K3s is running. For some reason this is blocking all traffic from any IP-address outside of the cluster to all pods with the label service. But it should block it only for the one IP address is specified in the except list.

Is this feature supported by the Kuberouter at all, or is it only for handling traffic between the pod, when they are talking directly with each other over internal network?

[brandond]

For some reason this is blocking all traffic from any IP-address outside of the cluster to all pods with the label service. But it should block it only for the one IP address is specified in the except list.

That's not what it should do. As soon as you add a policy that matches a pod, only traffic matching the policy is allowed. The rule you've created will only allow traffic from 10.2.201.0/24, except 10.2.201.113. All other traffic will be blocked because it does not match any other ingress rules.

[janbaer]

Maybe my explanation was not clear enough. The IP addresses that are allowed to send requests are all from the range 10.2.201.0/24 and the rule should allow it for all of this IP address range, except the one 10.2.201.113/32. But after activating this NetworkPolicy, all traffic was blocked, even the VM from which I tried to send a request had the IP 10.2.201.101/32, which should be allowed.

What worked for me was using an Egress-Rule and allowing the IP 10.2.201.114/32 to send requests to everywhere, except 10.2.201.113/32.

The IP range that is used internally within Kubernetes is not 10.2.201.0/24 by the way.

[brandond]

As noted in the upstream docs:

ipBlock: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable.

Cluster ingress and egress mechanisms often require rewriting the source or destination IP of packets. In cases where this happens, it is not defined whether this happens before or after NetworkPolicy processing, and the behavior may be different for different combinations of network plugin, cloud provider, Service implementation, etc.

IP blocks are not meant to be used to target traffic from nodes. For example when using the flannel CNI plugin, traffic from a node to pods on that node will appear to have a source address of the cni0 interface. Traffic from a node to pods on other nodes will have the source address of the flannel.1 interface. When using different CNI plugins, the behavior will vary from plugin to plugin.

See also https://kubernetes.io/docs/concepts/services-networking/network-policies/#what-you-can-t-do-with-network-policies-at-least-not-yet

• Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically).
• The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node).