Network Policy - Allow traffic from any namespace

[ClaudioSequeira]

Hello,

On course DO280 Chapter 04, Section 03 - Configure Network Policies, there is the following example:

##################################################################################

"By changing the podSelector field in the previous example to be an item in the from list, all pods in namespaces with the network=dev label and all pods from any namespaces with the app=mobile label can reach the pods that match the top-level podSelector field. This sample shows a logical OR statement.

...output omitted...
ingress:
- from:
  - namespaceSelector:
       matchLabels:
           network: dev
  - podSelector:
      matchLabels:
         app: mobile 

##################################################################################

On the other documentation (https://kubernetes.io/docs/concepts/services-networking/network-policies/), there is a similliar example (see below), it says that it only allows traffic from local namespace.

##################################################################################

...
ingress:
- from:
  - namespaceSelector:
      matchLabels:
        user: alice
  - podSelector:
      matchLabels:
        role: client
...

It contains two elements in the from array, and allows connections from Pods in the local Namespace with the label role=client, or from any Pod in any namespace with the label user=alice.

##################################################################################

I tested this configuration and it seems when there is only ingress.from.podSelector it only accepts traffic from local namespace. Can someone clarify this behaviour?

Thank you,

Claudio Sequeira

[laurpaum]

Multiple entries in the "from" (or "to") rules list are combined using logical OR.

Each entry MAY have a podSelector and a namespaceSelector.

If the namespaceSelector is absent, only the local namespace containing the policy is matched.

If the namespaceSelector is present with empty value, all namespaces are matched.

If the podSelector is absent or empty, all pods from the matched namespace(s) are matched.

You can't have an empty rule, so all pods in the policy namespace must be matched using an explicit empty podSelector.

The quoted explanation from DO280 is wrong.

[Mordonez]

As explained from the documentation, the namespaceSelector block allows you to specify one or more namespaces that meet the desired characteristics through labels, something that the podSelector block doesn't, potining by default to the current namespace that you're using.

[Chetan_Tiwary_]

Hello @ClaudioSequeira !

Thanks for reaching out !

I think you are right.

When you have only -

podSelector:
  matchLabels:
    role: client

  then it only accepts traffic from pods in the local namespace as per the Network Policy.

Whereas if you have - 

from:
- namespaceSelector:
    matchLabels:
      user: alice
- podSelector:
    matchLabels:
      role: client

This policy will allow traffic from pods in the local namespace with label role: client, or from pods in any namespace with the label user: alice

But this is not the same as this :

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          user: alice
      podSelector:
        matchLabels:
          role: client

This is AND operation : It selects particular pods within particular namespace. It is a single from entry.

I guess we can check the policy rule using oc describe networkpolicy <policyname> 

[Chetan_Tiwary_]

The explanation in DO280v4.12 ch04s03  seems right : Two different policies are shown with AND & OR rule.

[laurpaum]

The AND vs OR part is correct. What's not is stating that the rule with a podSelector and no namespaceSelector will match "all pods from any namespaces with the app=mobile label".

[Chetan_Tiwary_ · Accepted solution]

Hi @laurpaum !

Ah right ! It should be something like "It allows connections from Pods in the local Namespace with the label app=mobile, or from any Pod in any namespace with the label network=dev" 

Flagging this with the course development team. Thanks for specifying it explicitly.