Network Policy namespace ingress

Really struggling to wrap my head around network policies, could you please critic my solution to this problem? NB: The production namespace has a label name=production
Thanks
NetworkPolicy named test-network-policy in the existing namespace development. Ensure that the new NetworkPolicy allows Pods in namespace production to connect to port 8080 of Pods in namespace development.
Further ensure that the new NetworkPolicy:
• does not allow access to Pods, which don’t listen on port 8080
• does not allow access from Pods, which are not in namespace production

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: development
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: production
ports:
- protocol: TCP
port: 8080

Hello @cambell79 ,
Check this example https://github.com/ahmetb/kubernetes-network-policy-recipes/blob/master/07-allow-traffic-from-some-pods-in-another-namespace.md to be able to test it by yourself

I’ve seen all these I just asked for an opinion on my solution

Hi @cambell79

It’s quite difficult to see what this policy does as you have lost the indentation with the paste-in. If you use the code button on the message editor toolbar </> then it will format properly like so.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: development
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: production

You can use this tool to upload your policy document and view its effect visually, edit it graphically and re-download the updated policy.

Thanks for this resource @Alistair_KodeKloud. I think i’m struggling with ingress interpretation. So from my example, it is correct to say the pods in the development ns are the receiver of ingress traffic only from pods in the productionns? I have seen different interpretations of this hence the consfusion. What does it also mean if I use name: development in the namespaceSelector field? Like this:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: development
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: development

Hi @cambell79
Let’s first visualise your policy with the Cilium tool

From this we can see that ingress to the pod is denied from everywhere except pods in any namespace that carries the label development. If the development namespace does not carry the label name=development then other pods in the development namespace will not have access.

So if we were to create a new namespace production using the following commands, then any pods launched in it have ingress to the pod that has your policy attached

kubectl create namespace production
kubectl label namespace production name=development

With your policy, if it is the intention for anything in namespace development to access the pod, then you need

kubectl label namespace development name=development

and ensure no other namespace has that label.

A better way to achieve this, ensuring it can only be from pods within the development namespace is this

kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: development
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector: {}

Here we are saying all pods - but constrained to the namespace specified in the policy’s metadata -which looks like this
image

Note that

spec:
   podSelector: {}

will apply the policy to all pods in the namespace. so they can all talk to each other, but nothing from outside the namespace can talk to any of them.

Ok thanks I guess my problem is really that of interpretation. This statement for example " in the existing namespace development. Ensure that the new NetworkPolicy allows Pods in namespace production to connect to port 8080 of Pods in namespace development"
My understanding is that ingress is incoming traffic, so for the above we’re allowing incoming traffic from NS production to connect to pods in NS development using port 8080. Is this correct?

Targeting a specific namespace without you manually labelling them has a caveat.

If the result of

kubectl get namespace --show-labels

is something like

NAME              STATUS   AGE   LABELS
default           Active   18m   kubernetes.io/metadata.name=default
kube-system       Active   18m   kubernetes.io/metadata.name=kube-system
kube-public       Active   18m   kubernetes.io/metadata.name=kube-public
kube-node-lease   Active   18m   kubernetes.io/metadata.name=kube-node-lease
production        Active   18m   kubernetes.io/metadata.name=production

Then you can allow pods in production to connect to pods in development with this

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: development
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: production

If kubernetes.io/metadata.name labels are not present, then you must label the production namespace and use a matchLabels on the label you defined

Thanks for this @Alistair_KodeKloud, what if I just use name: production and ignore kubernetes.io/metadata? Is that still correct or I need to name it kubernetes.io/metadata.name: production
Also if pods in production are connecting to pods in development, is that ingress traffic for the development NS? ingress is like incoming traffic right?

Yes, ingres is incoming traffic. A network policy is effectively an in-cluster firewall.

You have to specify the full label name as i put it, if the cluster is set up to provide those labels., which you can tell with the kubectl get nodes command i gave you.

Is this a question from one of the courses? If so can you provide a link to it?

ok thanks. No the question is not from the course

Passed my CKA @Alistair_KodeKloud thanks a lot for all your help on clarifying my doubts

Congratulations @cambell79 !