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
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.
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:
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
Here we are saying all pods - but constrained to the namespace specified in the policy’s metadata -which looks like this
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
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?