Second section of the question asks to fix the issue where
I understood this as:
while the given lab answer tries to allow connection from frontend as source, towards backend pods
The original policy is this (we can ignore the other metadata)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-egress-restricted
namespace: ns-new-ckad
spec:
egress:
- to:
- podSelector:
matchLabels:
app: frontend
tier: ckad-exam
podSelector:
matchLabels:
app: backend
tier: ckad-exam
policyTypes:
- Egress
Which does this:
Allows pods in namespace
ns-new-ckadwith labelsapp: backendandtier: ckad-examto connect to pods in the same namespace withlabels app: frontendandtier: ckad-examon all ports
Let’s look at the pods and their labels…
student-node ~ ➜ k get po --show-labels
NAME READY STATUS RESTARTS AGE LABELS
backend-pods 1/1 Running 0 6m13s app=backend,tier=ckad-exam
frontend-pods 1/1 Running 0 6m12s app=frontend,tier=ckad-exam
testpod 1/1 Running 0 6m12s run=testpod
Fixing the network policy as suggested will mean that backend pods are no longer restricted from accessing anything due to network policy.
Now look at the services
student-node ~ ➜ k get svc -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
backend-ckad-svcn ClusterIP 172.20.61.134 <none> 80/TCP 7m35s app=back-end,tier=ckadexam
frontend-ckad-svcn ClusterIP 172.20.53.161 <none> 80/TCP 7m34s app=frontend,tier=ckad-exam
What do you notice about the service selectors? There is an issue here as well which needs to be fixed to pass the question.
Well my issue is that either the question itself or its answer has something wrong
The question wants to allow backend pods to connect/access frontend-ckad-svcn. this is already granted by original netpol that you posted above. Nothings needs to change in the original policy.
But maybe there is a typo in question syntax, and they mean to allow frontend-ckad-svcn to connect/access backend pods (the opposite direction). In that case the netpol will have to be changed to matched the one in the lab answer
Not quite!
student-node ~ ✖ k exec backend-pods -it -- bash
root@backend-pods:/# curl --connect-timeout 2 frontend-ckad-svcn.ns-new-ckad.svc
curl: (28) Resolving timed out after 2000 milliseconds
root@backend-pods:/#
The error is resolving timed out which means that the DNS cannot be accessed - that is the first thing that happens for any connection unless it is directly to an IP address.
If we make the required change to network policy, then it works because it can now do a DNS resolve
student-node ~ ✖ k edit netpol backend-egress-restricted
networkpolicy.networking.k8s.io/backend-egress-restricted edited
student-node ~ ➜ k exec backend-pods -it -- bash
root@backend-pods:/# curl --connect-timeout 2 frontend-ckad-svcn.ns-new-ckad.svc
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
Now can backend connect to backend?
student-node ~ ➜ k exec backend-pods -it -- bash
root@backend-pods:/# curl --connect-timeout 2 backend-ckad-svcn.ns-new-ckad.svc
curl: (7) Failed to connect to backend-ckad-svcn.ns-new-ckad.svc port 80 after 2 ms: Couldn't connect to server
root@backend-pods:/#
No it can’t. The problem is with the service selector as I already mentioned. Fix that and the question will pass.
You need to bear in mind with egress policies is that they nearly always do not do what you think they do because of DNS blockage. Quite often a restrictive policy will include the following
spec:
egress:
- ports: # Allow DNS lookup to anywhere
- protocol: TCP
port: 53
- protocol: UDP
port: 53
- to:
# Other policy
A question may not explicitly state this, especially in CKS. As a DevOps engineer, it is basic knowledge that clients requesting a service by name rather than IP will fail if they cannot resolve DNS, and that DNS listens on port 53 TCP/UDP.
So, putting the above in instead of changing the pod selector would also make the curl work, and would actually be more secure than just allowing the backend pods to access everything anywhere.