Kubernetes: Network policy - deny all with allow all

5/19/2018

I have a deny all by default policy across all pods in all namespaces. What if there is allow all added to a pod in a certain namespace. What will take precedence? Is there any and / or logic when combing multiple policies?

Thanks

-- user1578872
kubernetes

3 Answers

5/30/2018

Since we cannot specify priorities in network policy, the best way to solve your problem is to merge the two policies into one policy to avoid conflicting rules.

-- Yongli Chen
Source: StackOverflow

4/8/2019

Network policies whitelist connections, so there's an implicit OR there -- if a connection is allowed by at least one network policy, then it will be allowed.

A more detailed explanation (courtesy this guide):

Each network policy has a podSelector field, which selects a group of (zero or more) pods. When a pod is selected by a network policy, the network policy is said to apply to it.

Each network policy also specifies a list of allowed (ingress and egress) connections. When the network policy is created, all the pods that it applies to are allowed to make or accept the connections listed in it. In other words, a network policy is essentially a whitelist of allowed connections – a connection to or from a pod is allowed if it is permitted by at least one of the network policies that apply to the pod.

This tale, however, has an important twist: based on everything described so far, one would think that, if no network policies applied to a pod, then no connections to or from it would be permitted. The opposite, in fact, is true: if no network policies apply to a pod, then all network connections to and from it are permitted (unless the connection is forbidden by a network policy applied to the other peer in the connection.)

This behavior relates to the notion of “isolation”: pods are “isolated” if at least one network policy applies to them; if no policies apply, they are “non-isolated”. Network policies are not enforced on non-isolated pods. Although somewhat counter-intuitive, this behavior exists to make it easier to get a cluster up and running – a user who does not understand network policies can run their applications without having to create one.

-- viswajithiii
Source: StackOverflow

5/20/2018

It's not entirely clear from what I've found but the documentation hints at any allow taking precendence over deny:

Pods become isolated by having a NetworkPolicy that selects them. Once there is any NetworkPolicy in a namespace selecting a particular pod, that pod will reject any connections that are not allowed by any NetworkPolicy. (Other pods in the namespace that are not selected by any NetworkPolicy will continue to accept all traffic.)

Basically, applying a NetworkPolicy to any pod includes an implicit "deny anything else" policy. By creating a "default deny" policy you are able to isolate all pods as they're not targeted by any policy without it (no policy = no isolation).

-- embik
Source: StackOverflow